We have seen concerns and needs from both business and IT. Now we move deeper into a to-do list for architects followed by some practical advice.
About the data
Most of the prior discussion revolved around the data itself. Most of the effort surrounds the data, rather than this reporting tool or that one. Without clean, trustworthy, timely data – all is for naught. Enterprise data must be findable, available, and easy to use. It must be clean – clean enough for its intended use. I said “clean enough.” Don’t spend money unnecessarily and build a Ferrari when you only need a Chevy. Here is a reminder list of some things you should consider.
- How will the data move from the sources to the data store? What software will be used?
- What data goes into the data warehouse? What is the process for this determination?
- How frequently will data be refreshed?
- How will the data relate back to the source? When looking at rows in the data store – how do you know what source system it came from? You may need to know to fix bad data.
- Is the data getting cleaner or worse?
- How will you manage Data Quality?
- Does your data originate from multiple time zones, or involve multiple currencies? How will you handle that?
- Will you consolidate customer lists, product lists, etc and produce master lists? Now we are talking about master data management, along with its tools. Some of Mariner’s clients also implement a Data Stewardship program as well.
- How will support be handled?
- Do you need cloud/intenet data access?
- Do you need to import data from flat files, Excel, RSS feeds?
- How will reports/analysis be shared within the department or enterprise-wide?
- Will you provide a data warehouse, data mart or other ad-hoc specific data stores? How will those stores be kept in sync?
You will need some tools for:
- ETL (extract, transform, load) of data
- Reporting (ad-hoc) may be different tools for IT and end-users
- Data Stores (DBMS)
- Analytics and data mining
- Dashboards and scorecards
Try to standardize on a toolset, for economies of scale. However you must be able to allow for exceptions. Legitimate exceptions will exist – document them, have an exception process, and provide different tools when necessary. Ensure there is training, examples, best practices, advice and that the tools meet the actual needs of the business. Who is responsible for tool support?
Some Practical Advice
While all of the tasks mentioned above are big, complex, and perhaps worrisome, you do not need to do it all at once. Start small, with a specific business need. You should choose a proof of concept or project which you consider to be relatively safe. I mean safe from failure as well as low impact if there is a failure. Choose a project where you are collaborating with a good group of people. There must be a real business need, and the needers must be flexible and open-minded – good people to work with. You must work with the consumers directly, rather than through some intermediary, like an IT representative, or business analyst. We are working here for a high probability of success. You will learn from the experience. Then you will be in a better position to further articulate the architectural design you envision. Mariner has found that the use of an agile development process is best suited for delivery. It provides for a long term vision, but a short windowed work plan. This prevents fast-changing business requirements from becoming too burdensome.
Information Management Strategy
Now you should be ready to write your Information Management Strategy. You should include governance and accountability for the design and structure, storage, movement, quality, security and usage of information for business intelligence uses. Your strategy should also include an implementation plan.
If you wish, we can go into more specific options and solutions later.