We have published previous articles on the current reality of BI project challenges in the African context. Let’s do a quick recap on our 2015 findings to date on Business Intelligence Technology Selection – 5 Crucial points for IT and business Executives are listed. The aim of this article is to serve the project teams at our clients with some key learning points for starting off with BI technology selection. The goal is to promote time savings for BI selection and implementation and to speed up the process to provide the organization’s access to trusted, balanced and centralized information. This article does not advise our audience on any specific technologies or how to go about the selection itself.
1. In mind – project management challenges: Scope, Cost and Time. These three, hand-in-hand, are still the biggest competitors to quick BI value realization. Project Resourcing is now less of a problem for the generally implemented technologies in the African space. The technology you select, within the context of your organisational domain and architectural landscape, will largely determine the significance of these challenges during implementation. The reasons for these three elements can be further expanded upon in the next four.
2. Design as consideration during selection: Architecture and Integration challenges are the main contributors to the extension of scope and time in major BI implementations. A key learning to take into your project from the failures of others, regardless the technology for your core BI solution, is to ensure that the exact amount of integration required in your application landscape as well as how that couples with current architectural standards such as centralized master data management(MDM) and other components in a specific architectural model (eg. Service Oriented Architecture (SOA)) is scoped out well enough even before the selection and blueprinting is done. Having a clearly defined view of your integration scope and effort before entering the selection and design phases leads to less changes and scope creep during implementation.
3. Broader architectural change: The landscape for BI implementations have changed from an architectural perspective. The average large corporate now spends 30% of their annual IT budget on landscape redesign, optimization and revitalization to keep in line with sudden strategic business changes and unforeseen economic pressures leading to corporate restructuring, relocation, mergers and acquisitions etc. The consequence for BI is that it tends to play catch-up now more than before. There is no simple solution be it through governance or standard management practices to ensure this causes less delays on BI projects. The answer resides in having a truly scalable, yet loosely coupled BI design framework right at the core where the integration between data components become your reality. We strongly recommend that you do not engage any specific technology until your project team understands your architectural principles and challenges. Ensure that your design is ready for rapid change. The entire structure from base data through staging to cubes now, more than ever before, requires a flexible, ‘plugin-plugout’ design. More than a stock standard Kimble or Inman design is required to ensure that flexibility and scalability becomes an enabler to BI for sudden major landscape changes.
4. The belief that BI can ‘quickly become “real-time” and “in-memory”’. These words have become like the silver bullets, yet ever still not piercing the layers of IT kevlar compounding its challenge. Yes, there are numerous solutions to enforce the possibility of this belief. However, big-data still bares its constraints, not only by Moore’s law, but also by solid architectural common sense. Where data volume meets constraints which are uncontrolled by your chosen BI technology (eg. Large batch loads, flat file processing, delayed message queues, network lag and infrastructure issues, legacy integration), real-time is always an actual idea but still a very idealistic concept. The African context does not yet completely lend itself to real-time BI as much as the major BI technologies at hand may enable real-time and in-memory analytical capabilities by themselves. Senior Executives need to consider the constraints in their IT landscape before choosing to invest the ‘major bucks’ on the latest, most niche BI technology promising to deliver cross-organisational real-time performance views and dashboards.
5. Executive support: Mainly for reasons 2 and 4 above, executives are often frustrated with the amount of time and money invested to deliver singular, static reporting which could effectively be delivered with much more rapid and less costly approaches. Focus on providing your stakeholders with a proper short- to medium term VS long term BI strategy before engaging on a suitable technology investment, regardless the ‘bells and whistles’ on offer.
here are many different interpretations for the role of an Enterprise Architect. The role between enterprise and solutions architcture is even often blurred. This is understandible, given “enterprise architecture” have many different meanings despite well-known frameworks like Zachmann and TOGAF. We often find that there are only particular aspects examined to properly define these roles. To compound the issue, information technology professionals scope enterprise architecture differently. Some IT professionals view enterprise architecture as a more structured activity with many moving parts such as architecture strategy, architecture patterns, principles, architecture design, business architecture, and IT governance. Others may just focus on the technical aspects rather than the business, operational, or strategic aspects. Many view enterprise architecture as an IT-only issue. In many cases, it is important that the enterprise architecture group speak in both business and IT terms. In our opinion, most importantly, EA should be neutral in their functions in order to ensure architectural continuity and proper usage of its functions as opposed to being a ‘red tape’ function which can be seen by IT and business stakeholders as a ‘reactive obstacle’ to decisionmaking. The function of EA should thus be well balanced between governance and practical guidance to ultimately ensure that through governance the implementation of its selected/defined framework, throughout design to implementation, the solutions architects are enabled and guided. Yet its challenge is to remain relevant and actionable as opposed to its functions purely being focussed on technical aspects, playing ‘catch-up’ and documenting architectural outcomes in architecture models.
Recent Comments