If the business case is based on new or improved business outcomes, the business case is usually quite straightforward to generate. However, where technology is being replaced on obsolescence or deprecation, generating a business case that can be understood by the senior leadership team and Board can be challenging.
Traditional ways of describing the IT infrastructure are highly specialist – understood (hopefully) by the CIO and CTO but baffling to the CEO and CFO. LINQ focuses on describing an information ecosystem in terms that can be readily understood by all executives; as an information supply chain. An information supply chain connects sources of information to decision support applications.
We can describe a single supply chain as a triangle with sources of information at the base and the decision support applications at the top:
Where an organisation has more than one decision support application, we would hope to see information reuse:
We can use that approach to map out the current state for a Google Enterprise user which might look like this:
This is a simple exercise which maps out how your sources of information relate to your applications; then layering on the enablers of those sources (the servers) and applications (the vendor application frameworks). Simple and powerful. That’s because we can immediately explore priority areas based on what’s being deprecated and what’s not. Google Earth is not being deprecated so why replace it? GME and GEE are being deprecated. That shows us where we need to focus:
The red apps and sources will need rework. The red spatial information supply chains will need to be completely re-worked; the orange will likely need minor rewiring and the green areas are not a priority for now. LINQ can take this high-level view and trace the specific information supply chains in terms of information source – action – derived information – action – information – action… and eventually application. We can show how people and systems enable that information flow. This provides a view of the current state and scale of the challenge in terms that the CIO can communicate to the CFO and CEO; a critical step in gaining support for action.
The video below explains how we capture this detail… and gain an understanding of how costs aggregate up across those supply chains. This shows our Proof of Concept which we are moving to Minimum Viable Product in the coming months and then onwards to version one. The MVP will have more capability and some design applied to it. Watch this space!
We’re planning for the next post to focus back in on some of the unanswered questions we all have about the Google / Esri relationship… and then we’ll go into more detail about LINQ.
[…] "In the last post, I explored the need for a strategy and roadmap to guide the migration from Google’s deprecated products. In this one, I’ll discuss a methodology which could be used to structure a spatial strategy. At Spatial.IQ this methodology is at the heart of our consultancy and is called Spatial.LINQ. No matter how simple the transition from Google to Esri is in technology terms, it will incur unplanned capital expenditure and a shift in operational expenditure. At the very least, that’s going to need a conversation to seek approval. In most organisations, gaining that approval will demand a business case to be presented at the budget approval level." Read more at http://spatialiq.co.nz/index.php/spatial-iq/how-to-plan-your-migration-from-google-to-esri/ […]