Caroline Hermon

3月 062017
 

We like to think of analytics as a logical discipline, where investment decisions are consistently rational and predictable. Not so. Customer organisations are driven by all the usual complex and sometimes contradictory forces. Business users want analytics to help them make good customer facing decisions as quickly as possible, while [...]

How to make analytics modernization work in practice was published on SAS Voices by Caroline Hermon

1月 302017
 

I’ve had several meetings lately on data management, and especially integration, where the ability to explore alternatives has been critical. And the findings from our internet of things (IoT) early adopters survey confirms that the ecosystem nature of data sources in IoT deployments means we need to expand the traditional […]

It’s data integration, but not as we know it was published on SAS Voices.

8月 122016
 

Data monetization, at its simplest, is the process of turning data into bottom-line value for a company -- often through improving efficiency and/or customer experience, and building customer loyalty as a result. This may sound simple, but in practice, it’s anything but. Good data, advanced analytics and real-time decision making […]

Monetizing data from the IoT was published on SAS Voices.

3月 312016
 

While the growth of big data is an issue that preoccupies both the public and private sector, it’s also high on the UK government’s legislative agenda. All eyes are currently on the authorities, as we wait with bated breath to see what’s next in the quest to manage data escalation. […]

Treading the murky legal waters of big data was published on SAS Voices.

10月 142015
 

sizingSizing is a topic that solutions managers typically leave until the end after decisions about the application have been settled. But there are often many variables that can impact the final size requirement. We have seen across our customer base that sizing and the number of environments has been determined by predicted data volumes, the types of environments that need to be supported and the budget available.

Environments

Technical architects spend time debating what environment is right for their business and of course this is no easy decision.  Often the business changes its mind, data volumes increase (often with little or no advance warning), data sources vary, different teams need access and with this performance issues creep in.

Production – this one is a must so is easy to say yes to. It’s perhaps the easiest of the estimates as long as the solutions team is able to predict the volume of data.

Undersizing is a common problem here for many reasons. The most common reason is when the solution has been far more successful and has attracted more users, and/or data sources. The second common cause of this is where the procurement team has persuaded the solutions managers that they can make do with less resources. Finally we also sometimes see incorrect assumptions being used when sizing.

Test – what and when will be tested, and how frequently, are the key questions here

Development – Increasingly we are finding customers trying to minimize the environments. However, for data quality a development server is pretty key to have in place. Don’t let the development server be an afterthought.

Architecture workshop

The most effective way we found to determine optimum sizing is an in-depth workshop with an experienced architect. But such a workshop typically requires a lead time of two-to-four weeks to set up as experts review requirements and work on proposed options. The fallacy of budget constraints - companies may try to save money by reducing environments, however this can end up costing more.

Sometimes though, solutions managers discover very late in the implementation cycle that they need to revisit their sizing/number of environments.   If a resizing has to take place, additional budgets secured and a reworking of the installation, this can have a real impact on time/resource/cost and more importantly the time it takes to start gaining business benefit.

In such situations, we have found three workarounds:

  1. Spend time with the vendor’s architect team to understand what is required now and moving forwards – get advice
  2. Understand the business’s expectations and requirements for the next 24 months so it’s a robust scaleable solution
  3. Get back on track as soon as possible so the business can realize value from improved data quality/analytics/access to Hadoop etc.

Interesting article here by David Lashin virtualised environments.

Communication is king throughout the sizing exercise - between the technical teams of both vendor and customer and between the business and IT teams about exact usage, data volumes and critically growth plans for the coming 12-to-18 months.

Summary

Across all organizations we see various debates happening – our advice is get this topic out on the table and into the open as early as possible. It is critical to the success of any project, it will enable the deployment to be smoother and the adoption and therefore the time to value will be reduced (which is critical).

We would love to hear from you – does any of the above resonate with you? Have you had good/bad experiences? Share your thoughts with caroline.hermon@sas.com

For more hot topics follow me @hermon100 for more tips from Caroline at the Coalface!

tags: data management, SAS architecture, sizing

Sizing: the long and short of it was published on SAS Users.