A data superhero is something to be

A data superhero is something to be

A data warehousing superhero is something to be

Not all that glitters is Big Data, and Big Data has a long way to go before it can deliver anything like the same satisfying results, tangible benefits and organisational agility that a properly implemented Inmon Enterprise Data Warehouse can provide.

Therefore, I have a question for you.

Do you want to win friend and influence people in the world of data architecture and management? Do you want to do something in IT that atypically will bring kudos and credibility? Do you want to enjoy what you are doing because you are actually doing the right thing right for an appreciative audience?

Okay, this a recipe that I will now reveal, has the power to turn you into, not only a data hero, but a 4^th generation enterprise data warehousing superhero – with Big Data bells and whistles attached, and even more amazingly, it is offered for nothing, gratis, and for keeps.

Yes, you read it right. I am feeling generous, and although a rare animal, there is such a thing as a free lunch. In this instance, the free lunch takes the form of a cookbook for successful data sourcing, warehousing and provisioning, one that will turn you into a truly modern day digital superhero.

Follow the suggestions to the letter and it will be hard to fail. However, drop any magic ingredient from the mix and expect, eventually, to run out of luck – that is rhyming slang for Donald Duck, down my way. Almost as important, please apply your own criteria of good sense at every step of the way.

The craft of data  

The craft of data includes temporary-permanence in exploitation, revolution and institution.

When Sun Tzu was talking about the Art of War, he was also talking about the craft of data.

In the 21^st century the highest expression of the craft of data in an organisation, whether public, private or military, is the enterprise data warehouse.

These are some of the key rules and guidelines for ensuring that you prevail and not your adversaries. The items are necessarily terse, but should provide a sound basis for further research, thought and strategic practice.

So without further ado, let us get to the crux of the matter.

1.       This is the first piece of advice, and it's a little bit of a 'downer', but you may just thank me for it later. The business sponsor of any significant Data Warehouse initiative or iteration cannot be the CIO, CTO or any member of the IT organisation. When this unfortunately happens, and it happens far too often, you should know that this particular data warehouse project is dead before it even gets off the ground - guaranteed. If you can afford to walk away from such a project, then do so. Now for the more positive aspects.

2.       All data in the data warehouse must be subject-oriented.

3.       We must integrate all data before it enters into the data warehouse.

4.       All data in the data warehouse must be time-variant or specifically indeterminate.

5.       Data in the data warehouse must be non-volatile – within periods of explicit and implicit snapshot coverage.

6.       Data in the data warehouse is primarily used to feed into management decision making (by order of importance: strategic, tactical and then operational).

7.       We build the data warehouse iteratively and over time. We never build the data warehouse using a 'big bang' approach.

8.       We base each build iteration of the data warehouse on a specific set of well-bound departmental-oriented requirements, deliverable in a short and specific timeframe. We never try to build the data warehouse using a 'boil the ocean' approach.

9.       We never run more concurrent iterative developments in a data warehouse programme than we would in any other agile environment. This means that for a mature data warehousing setup, we run a maximum of five concurrent developments. The more immature the organisation, the less the number of concurrent iterations.

10.   We use a contemporary two-tier approach to the data-warehousing super-component. A well architected, designed and engineered third-normal form database that supports true historicity and time-variance-modelling forms the basis of the decision support database of record.

11.   We build departmental and process-centric data marts on top of the data warehouse layer, as the end-user-centric semantic-layer of the data warehouse.

12.   We use 3NF to model the data warehouse data-model. We typically use dimensional modelling to model the data mart models, although other modelling options are also valid. Target use cases will inform the decisions we make regarding the choice of data mart model.

13.   Never trust anyone who claims that we can service the strategic data needs of a complex and volatile enterprise by implementing a faux data warehouse built using a collection of conformed dimensions and facts. This approach may initially appear to work, however, this is a massive strategic, tactical and operational mistake, which will eventually involve costly reengineering, loss of valuable data, organisational disruption and dissatisfied clients.

14.   We store transaction in the data warehouse at the lowest possible level of granularity. We store transaction and fact data in the data marts at the aggregation levels appropriate to the target audience.

15.   Based on use cases and performance needs, we will accordingly aggregate data in the data marts. If, in the future, lower level data granularity is required in the data mart then we can easily provide that by reconstructing the data mart from atomic level data stored in the data warehouse.

16.   We should never second-guess business requirements. No business imperatives means no requirement. You're aiming to be a successful data superhero, keep that goal in mind. Don't be beguiled into doing the wrong things even when accosted by 'right-sounding reasons'.

17.   Data warehousing is about the permanent incremental development and redefinition of minimum viable products and a minimum viable service. Iteratively grow the data warehouse and ignore those who claim that Inmon is about 'big bang', 'bottom up' and 'boil the ocean'.

18.   Avoid pork barrel political games in data warehouse programmes. You should not use a data warehouse programme as a means to leverage a raft of other related data, operational and DevOps projects in the organisation. For example, Corporate Data Governance, Data Quality and Disaster Recovery/Business Continuity should not packed into the data warehousing programmes, at any level. Again, this is a massive strategic, tactical and operational mistake.

19.   We ensure that as a minimum that data in the data warehouse is as reliable as the data at source. Simply stated, we do not allow unnecessary entropy to effect the data in the journey from source systems to the target data warehouse or data marts.

20.   No data is 'corrected' or 'cleaned' in the data warehouse without the explicit, verifiable and express consent of the fiduciary duty holder with respect to that data. If the data warehouse is to act as a system of record then it must also hold metadata relative to any 'cleaning' that has been applied to that data, and should also hold 'before' and 'after' states of corrected data – for auditing purposes.

21.   We secure all data in the data warehouse in accordance with prevailing legislation and corporate rules and guidelines. In any conflict between corporate rule and legal jurisdiction, the current laws prevail.

22.   Ensure that competent and independent design authorities, with the support of the Data Warehouse architect, are ultimately responsible for all data-warehouse architectural, process and design decisions.

23.   Architectural and process choices govern the selection of methodology, product and partner. Always remember mens sana in corpore sano. Prejudice, speculation and opinion generally lead to very bad data-warehouse acquisition decisions, and can potentially lead to strategic, tactical and operational mistakes.

24.   Data warehousing iterations have clear top-level phases: start-up; DW management phase; analysis phase; design phase; build phase; testing phase; and, implementation phase. We complement these phases with data warehousing tracks: project management track; user track and requirements; data track; technical track; and, metadata track. This approach is used by a number of data warehousing methodologies, including the Cambriano methodology for data warehousing, information management and data integration.

25.   To conclude, I would like to iterate some of the reasons why we should follow an Inmon based approach to the building of a Data Warehouse. The Inmon approach is very much based on:

                    i.            Iteratively solving specific business challenges, iteration by iteration. This is not just a flippant excuse for spending other peoples' money. The Inmon DW is not about 'boiling the ocean', 'bottom up' or 'big bang'. Neither is it an insistence that one can build a whale by carefully configuring a collection of minnows. There's a 'little bit more' to it than that.

                   ii.            Delivering perceived and visible value within a reasonable timeframe.

                 iii.            Achieving high returns on investment.

                 iv.            Meeting or exceeding expectations.

                  v.            Meeting user requirements, first time and every time.

                 vi.            Delivering a quality data-warehouse solution on schedule, within budget, whilst effectively utilizing the resources available.

               vii.            The rational and economic need to minimize the impact that any strategic data initiative will have on operational systems and the organisation.

              viii.            The goal of maximizing information availability and analytical capabilities throughout the organisation and even to stakeholders and clients, if we so wish.

                 ix.            Designing towards maximum flexibility to ensure that we can accommodate much of the future decision support needs immediately and that we swiftly and coherently address new requirements.

Now what?

Now I've given out a wealth of valuable information and indications you may be asking 'and now what?'

This is the next step, dear budding data superhero:

1.       Take each of the items mentioned above and study them to the best of your ability. Do lots of research, and start to fit together the pieces of the jigsaw.

2.       Invent scenarios, or better still, ask other people for scenarios and hypothetical challenges, and then work through how you would go about responding to those scenarios and challenges.

3.       If you have any questions that you cannot research and answer yourself, then I will be glad to help. That is, if the request is regarding a particular aspect of data warehousing or management. Please email me your questions at martyn.jones@cambriano.es Please use one email shot per question please (e.g. if you have three questions, send three emails), so that I can prioritise the questions and manage the time I can set aside to respond to them.

The subtle evolution of Inmon's definitive Data Warehousing

What I have described are elements and requisites of a solid, coherent and cohesive approach to fourth generation Enterprise Data Warehousing, a proven approach to the provision of quality data for management decision support. The approach is the evolution of the classic Inmon approach, which has evolved over the intervening decades, thanks to Bill Inmon himself, and those who adopted and developed his approach to cohesive, coherent and comprehensive data warehousing.

Many thanks for reading

So, that's it. Many thanks for reading this piece and I sincerely hope you found it of interest.

Do keep in touch. You can connect with me via LinkedIn and you can also keep up to date with my activities on Twitter (User handle @GoodStratTweet) and on my personal blog http://www.goodstrat.com (GoodStrat.com)

I am the manager of The Big Data Contrarians group on LinkedIn. Consider joining that group, if only for the critical thinking that it could potentially provoke.

You may also be interested in some other articles I have written on the subject of Data Warehousing.

Data Warehousing explained to Big Data friends - http://goodstrat.com/2015/07/20/data-warehousing-explained-to-big-data-friends/

Stuff a great data architect should know - http://goodstrat.com/2015/08/16/stuff-a-great-data-architect-should-know-how-to-be-a-professional-expert/

Big Data is not Data Warehousing - http://goodstrat.com/2015/03/06/consider-this-big-data-is-not-data-warehousing/

What can data warehousing do for us now - http://www.computerworld.com/article/3006473/big-data/what-can-data-warehousing-do-for-us-now.html

Looking for your most valuable data? Follow the money - http://www.computerworld.com/article/2982352/big-data/looking-for-your-most-valuable-data-follow-the-money.html

Martyn Richard Jones

Palma de Mallorca

23^rd September 2015

The golden age of Big Data bullshit

Without a shadow of doubt, we have entered the golden age of Big Data bullshit.

In these postmodern times of always-on, instant-gratification, and vain superficiality; where crapulence has become the new credible, mean boloney the new benign and trite the new treasure; it is hardly surprising that banality has been elevated to the status of wisdom and knowledge.  

So, in spite of what the good people at the prestigious house of Gartner have been saying, the Big Data hype-cycle is far from over. This is why I believe that we have entered what might be fairly albeit humorously described as the golden age of Big Data bullshit.

Now, I remember the renaissance of Data Warehouse boloney, and some of it was outrageous, and in many cases perpetrated by the very same companies (and in some cases, people) who are now spreading the Big Data doo-doo around, thick and fast. But although it has some parallels with the golden age of Big Data bullshit, the comparison doesn’t really do justice to either.

When I started on my first Data Warehouse projects, there were no Data Warehouse success stories in Europe, it was just all too new. Sure, I had been doing things like managing the design and build Information Centres and MIS solutions in the eighties, and the projects I was involved in and responsible for were largely successful, but they weren’t the full-Inmon DW enchilada, and sometimes these solutions became unstuck and in unpredictable ways. Later, with satisfied DW users and successful deliver of DW projects, came a slew of tangible, coherent and verifiable success stories. But it wasn’t all about success, as more than fifty percent of so called Data Warehouse projects were accidents waiting to happen. Nonetheless, there were enough tangible, coherent and verifiable Data Warehouse success stories around that the task of providing this sort of information to interested parties wasn’t turned into an onerous task of ‘inventiveness and creativity’.

Up until that point, at least on my own Data Warehousing projects, success was based on the understanding that for success to be assured the process had to be absolutely business driven, market focused and technology based.

Sometime around 1995, technology companies realised that Data Warehousing was no longer going to be a simple niche solution. So what did they do?

I’ll tell you.

All of a sudden new and massive marketing campaigns were oriented to ensure that Data Warehousing was seen primarily as technology driven, technology focused and technology based. Even if the supposed outcome was to be a large population of pleasantly surprised DW users and business stakeholders. The key to all things wonderful in DW land was to be technology. Technology, technology licenses and technology services.

So, what happened next?

Well, the massive-shift to Data Warehousing as being mainly a technical solution almost killed the fatted calf, the goose that lay the golden eggs and almost gave away all of the Data Warehousing the family silver, in one fell swoop. From those days, the world of Data Warehousing never truly recovered from that massive cluster**** - a massive and naïve act of Homeric strategic incompetence committed by those in the IT industry who should really have known better.

Big Data is like that, but worse. There is no Inmon of Big Data. There is no coherent development process. Unsurprisingly really, as there is no real equivalence at both the business or market level, and what connections there are between technologies employed in both are almost purely coincidental.

Inmon Data Warehousing was a pragmatic and business oriented solution framework looking for technologies. It was side-lined by corporations looking to maximise their hardware and license sales, and by service providers who based their models on maximising offshoring, maximising hours worked per artefact, minimising quality and by creating and selling seriously dodgy contractual agreements.

Big Data is about niche ‘roman census’ technology looking for a problem. So far, in many domains, where no suitable and obvious challenge actually exists.

So, Big Data is an entirely distinct proposition.

One way or the other, like it or hate it, so bereft is the Big Data world of success stories, beyond the usual triad of Google, Facebook and Amazon, that the leading influential pundits of the day are ‘obliged’ to eke out success stories elsewhere.

How many times have we read Big Data success stories, that…?

1.      Were actually success stories from another area, such as a success story from Data Warehousing or Business Intelligence or Statistics?

2.     Weren’t actually success stories at all, but lazy, misleading and inaccurate notions about how Big Data might be applied.

3.     Were simply taking advantage of some human tragedy or another in order to schlepp Big Data snake-oil medicine around the social media.

Sure, it's all nonsense. But it's nonsense that means that evwerything becomes much more complex, and unnecessarily so. That things are done that should not be done, that projects fail that should not fail, and that any superficial initial savings on offshoring are wiped out because deliverables are basically unusable.

So, when I hear terms such as ‘amazing’, ‘guru’ and ‘influencer’ mentioned in connection with Big Data, well, what more can I do than reach for a nice cup of tea.

That's quite enough about that for now. I hope it makes sense to you and that you can avoid any nasty surprises in the future. Whether in Big Data or Data Warehousing.

Many thanks for reading.

As always, please share your questions, views and criticisms on this piece using the comment box below. I frequently write about communication, data, information, knowledge, strategy, organisational leadership and information technology topics, trends and tendencies. You are more than welcome to keep up with my posts by clicking the ‘Follow’ link and perhaps even send me a LinkedIn invite. Also feel free to connect via Twitter, Facebook and the Cambriano Energy website.

Finally, if you feel up to being a member of the elite Big Data Contrarians community then please send in a request to join from this LinkedIn page:

https://www.linkedin.com/groups/8338976

Big Data with BIG SMILES

Having got your attention I would like to introduce you to a pragmatic, real-world and business centric approach to Big Data and Big Data Analytics. When I say that this is the best approach to Big Data you are ever likely to find in the whole universe and in your entire life, I am still significantly understating the magnificent utility, timeliness and the here-and-now facets of the approach.

Now with the introduction done and dusted with, and the virtues of the BIG SMILES approach exalted, it should come as no surprise that this eminently sensible, highly rational and thoroughly reasonable methodical and no-nonsense technique has been applied successfully in more than 500 business-oriented situations.

Best of all, this amazing Big Data approach is free of charge and with no-strings attached – you don’t even have to buy my book. Now, isn’t that amazing?

Let’s start with the basics. The BIG in BIG SMILES refers to Business Insight Gains. This refers to the focus of SMILES. Simples, right? Now what does SMILES refer to:

Fig. The process chain of Big Data SMILES

SMILES is also an acronym, and it refers to the six major components of the SMILES Big Data approach (as illustrated above). Or, more precisely the various phases of the approach. Namely:

1. Start with a significant data-centric business challenge
2. Model high-level options and approaches
3. Implement your chosen option
4. Leverage the products
5. Evaluate performance and value
6. Socialise the outcomes

Let’s take a look at each of those aspects of Big Data SMILES in a little more detail.

1.      Start with a significant data-centric business challenge

It makes sound business sense to start any business initiative with a compelling business reason. If you don’t have one then don’t start, it’s as easy as that.

Fig. Start SMILES

Now, having identified your significant business challenge you should ask the following questions:

• What: What do you want to accomplish with respect to the significant business challenge?
• Why: Why do we want to address the challenge?
• Who: Who should be involved in helping address this challenge?
• When and where: Can you identify the time and place the challenge first comes into effect?
• Windows of opportunity: During what periods can we most effectively address the challenge?
• Which: Can you enumerate the requirements and constraints associated with the challenge and the possible responses?

When compiling your view of the significant business challenge, you could look for example at questions along the lines of:

1. How do I find the Big Data I need?
2. What is the original source of the Big Data?
3. How was this summarization, enrichment or derivation created in the Big Data?
4. What queries and mechanisms are available to access the Big Data?
5. How have Big Data related business definitions and terms changed?
6. How do interpretations of the Big Data/Data vary across organizations?
7. What business assumptions have been made that are related to this Big Data?

Don’t forget, asking great questions about significant business challenges will lead to even more questions, which is where you will want to highlight the new questions that could quite possibly be answered, wholly or partially, using Big Data. Also, don´t confuse great questions with complex questions, the idea is not to impress the audience but to identify and address the challenge.

Another important thing to point out in relation to the SMILES approach is that you should never, ever, in no way shape or form, try and boil the ocean. That is, do not try and implement and leverage Big Data analytics in your organisation in big leaps and bounds. Start out with baby steps, and treat it like a game of tennis. Win points, games, and sets and beat challenges and bad decisions one-step at a time.

Finally, make sure each iteration of SMILES starts with an objective that is big enough to be significant yet small enough to be doable in a reasonably short-time scale, one preferably made up of sprints of no more than 5 to 10 days.

2.      Model high-level options and approaches

Here we are looking at a process of discover and insight; conceptualisation and creativity; deign and innovation; and, prototyping expertise and domain capabilities.

Fig. Model SMILES

This phase has three parts:

1. Defining the problem and developing options
2. Evaluating and selecting the best model
3. Finalising and developing the implementable prototype

Defining the problem and developing options

Using Co-operative Prototype Ideation, Concretisation and Realisation (a unique rapid development feature of SMILES), you may now choose to develop options and models to various stages of maturity and extensiveness.

Evaluating and selecting the best model

Through a cycle of hypothesise and test you may arrive at the model most suited to your needs. If however, no such model is forthcoming or the best model simply is not good enough or promising enough then do not proceed to the next step. Make sure you have a good reason to progress and inertia is definitely not a good a reason, and neither is ‘because we have to do something’.

Developing the implementable prototype

In this phase, you develop the chosen model through to the stage where it is ready ‘productised’ in the following prototype implementation phase.

In addition, as part of this phase, you will be looking at which technology options might provide the best fit with your requirements. Common technological options are typically associated in one way or another with the Hadoop ecosphere, so your problem may be adequately addressed using technology such as Hive, Pig, Bash, Spark or Python, or indeed with products such as MapR, Neo4j or EXASol.

3.      Implement your chosen option

In this phase, you take your well thought out proof of concept prototype and turn it into a business ready and production hardened product.

What is involved in turning a Big Data solution prototype into a product?

Here we are focusing on tools, build competence and teamwork; product piloting and development support; and, the realities of production and support.

Also, as a closing message for this phase description, please note that the implementation phase also includes the active participation of the development sponsors and target user group, as should every phase up to this point, and all of the follow on phases.

4.      Leverage the product

It’s been designed, prototyped, built and productised. Now what?

Well, here comes the moment of truth.

In this phase SMILES can help Big Data teams quickly react to changing business and market needs by capturing and managing new and changing requirements, and by constantly monitoring feedback. The framework can be totally integrated into true agile development processes especially where requirements are extremely dynamic and free-flowing but nonetheless must be managed at a complete Big Data product level.

5.      Evaluate performance and value

An assessment of the value of the Big Data initiative should be made periodically. However, there should be at least four event-pegged must-do valuations carried out during the life-time of the project products.

Fig. Evaluate SMILES

1. Initial acceptance criteria alignment and qualitative valuation.
2. Maturity performance and tangible ROI contribution. Include both the mitigation and avoidance of loss and the enablement of all direct and indirect gains.
3. Life-time-value-to-date to be carried out before all major enhancements.
4. Sunset life-time assessment and valuation. On replacement or withdrawal from service.

6.      Socialise the outcomes

These are the activities that generally put the smiles in SMILES.

Whatever happens with your initiative you must never fail to socialise the outcomes, for as kitsch, cute or painful the exercise may appear to you or anyone else.

Put it this way. You’ve gone to all the effort and trouble of making a Big Data initiative work, and it’s working well, people like it and it’s delivering value. So, what else is there to do? It’s a success, so you shout it from the rooftops, tell all your colleagues and peers, put the news on the intranet and in the company house magazine, and organise a party.

If your project is killed off early or late, or simply fails to deliver value, and sometimes this just happens, then hold a wake, in the Celtic manner, and learn all the lessons that are worth shaking a stick at and make them part of your corporate data management story and knowledge base.

The golden rules of SMILES for beginners

When entering the new dynamic world of Big Data and Big Data Analytics and to ensure that SMILES delivers the kind of success that others enjoy, you must take ensure that the 9 golden rules of SMILES are also followed. These are the golden rules for beginners.

Fig. The 9 golden rules of SMILES

1. Infrastructure – Ensure that the infrastructure is adequate for the needs of the project and ensure that executive management disconnects your prototyping, development and deployment cycles from the necessarily rigorous, time-consuming and constricting requirements imposed on core business operational systems. Remember this is operational, but it is not life threatening, customers will not be lost nor will serious money be burned. So make sure your senior management unchains Big Data from Big IT bureaucracy – and if possible, on a forever basis.
2. Pilot – When you first take on Big Data and Big Data analytics, always start with pilot prototypes and projects. Again, small enough to be doable (avoid overreach at all costs) and large enough to be significant (small and useful doesn’t have to be trivial).
3. Timescale – Aim to deliver initial pilot Big Data prototypes in around the 3 to 6 week mark, and aim to get the first projects into the leverage phase in around 3 to 5 months, tops.
4. Long-term – Aim to deliver fast, simple and elegantly, but also keep a keen eye on the long-term prospects and issues for Big Data and Big Data Analytics.
5. Cash-flow – Control the cash but make sure you have enough to do what you need to do. Focus on value, keep sprints and iterations short, and be intelligent in the management of funding. (see comments on funding later in this piece)
6. Continuous involvement and justification – Justify every decision in terms of business (mandatory) and technological (optional) drivers. Involve business partners, continuously. Make this an absolute mandatory condition for starting the project and continuing. If involvement from business stops, then stop the project until the implication and involvement of the business stakeholders picks up again. Make all of this clear from the outset. Continually seek and reaffirm business justifications for the projects existence – this is a showcase, and people are watching.
7. Sponsors – Ensure that your project has high-level business sponsorship. This cannot come from IT and it cannot come from the CIO or the CDO, unless your Big Data project is to measure and report the performance of aspects of IT and Data Governance.
8. Clean – Make sure that the data that you use is to the quality levels required. The data that you analyse must be at least as good at that stage as when it was sourced. In many cases you will need to scrub and clean data, especially when it’s coming from badly designed, tragically engineered and shoddily built web applications where the designers and developers have only had a passing acquaintance with sound database engineering principles, if at all.
9. Tenacity – finally, never give up until it’s time to do so. If you believe that success is achievable then go for it. If you see that the project is on a suicide mission then kill it quickly, don’t wait until you’ve burned all your hours and cash.

When using SMILES keep these 9 golden nuggets of rules in mind, and you won’t go far wrong.

A note on funding

Try to make sure that your funding aligns with the phases of SMILES.

However, split your funding requests into three parts.

• Start with a significant data-centric business challenge. 2. Start with a significant data-centric business challenge. 3. Model high-level options and approaches.
• Implement your chosen option.
• Leverage the products. 6. Evaluate performance and value. 7. Socialise the outcomes.

This ensures an optimum allocation of resources and provides additional executive and project management safeguards and options, and helps to ensure alignment of contractual assurances and obligations with committed and planned budgets.

A note on testing

Testing is an integral element of every phase of the SMILES approach. For brevity the approach has not been detailed in this document, but the philosophy is essentially one of test early and test often. Under normal circumstances the SMILES approach does not require a User Acceptance Testing phase, and if we are in shops that do require this testing then the UAT becomes a mere bureaucratic formality.

Things to remember

Some people may be surprised that the Big Data SMILES approach does not start with a strategy. In my view, the idea that strategy can begin without the need for identifying a significant challenge is to get things wrong on two counts: i. It’s not the way to go about strategy, and ii. It’s not the way to go about Big Data.

The BIG SMILES approach is not in itself a strategy, it is a guide, reference and framework for those who wish to develop a specific Big Data oriented strategy for addressing a significant business challenge. This is where it is powerful, useful and relevant. It’s a roadmap, a cookbook and a method to understand issues, formulate questions, and provide adequate, appropriate and timely responses, whilst separating the wheat from the chaff, the core from the periphery, and the important from the inconsequential.

Lastly, if you or your Big Data analysis, design development team haven’t done so already, I suggest that you take a look at the Cambriano Information Supply Framework, which provides a solid-basis upon which to architect and design Big Data oriented solutions.

That’s all from me for now. Have fun and enjoy the Big Data journey.

Thank you for reading.

If you would like to know more about SMILES, the Information Supply Framework, Core Statistics, Core Data Sourcing, Data Governors, the Analytics Data Store or 4^th generation Enterprise Data Warehousing then please drop me an email or visit:

http://www.cambriano.es

On a lighter note, readers may also be interested in joining The Big Data Contrarians, the friendliest, most relevant and massively irreverent Big Data community on the whole of the entire world wide web. So, if you think you are up for it then we can be found on LinkedIn at this address:

https://www.linkedin.com/groups/8338976