Get started Bring yourself up to speed with our introductory content.

Creating an information management strategy for high ROI, low TCO

In a book excerpt, consultant William McKnight frames a plan for building and managing an effective information architecture to benefit the business.

This is an excerpt from the first chapter of Information Management: Strategies for Gaining a Competitive Advantage with Data, written by William McKnight and published in December 2013. McKnight is president of McKnight Consulting Group, a business intelligence, big data and data management consultancy. In the book, he addresses the relationship between information management and business value, explores data management technologies, and offers advice on maximizing the potential of enterprise information.

Information Management: Strategies for Gaining a Competitive Advantage with Data

In this excerpt, McKnight introduces his overall information management strategy, which includes continually analyzing business operations and instituting a data architecture that unites information components but remains flexible in order to accommodate the inevitable changes driven by new business requirements.

Turning information into business success

Today, you need to analyze your business constantly and from multiple perspectives or dimensions. There are the perspectives of the customer, the products, services, locations and many other major dimensions of the business.

The high value comes from analyzing them all at once. You cannot simply set up a storefront, declare you are open and begin to let the business run on autopilot from there. You must analyze the business. Information architecture is the key to organizing information.

The glue is architecture

Information must come together in a meaningful fashion or there will be unneeded redundancy, waste and opportunities missed. Every measure of optimizing the information asset goes directly to the organization's bottom line.

The glue that brings the components together is called architecture. Architecture is a high-level plan for the data stores, the applications that use the data and everything in between. The "everything in between" can be quite extensive as it relates to data transport, middleware and transformation. Architecture dictates the level of data redundancy summarization and aggregation since data can be consolidated or distributed across numerous data stores optimized for parochial needs, broad-ranging needs and innumerable variations in between.

Workload success

Even organization leaders can take a tactical approach to the execution of the requirements. However, it does not necessarily take longer to satisfy information requirements in an architected fashion. If architecture principles and technology possibilities are not considered beforehand, the means to satisfy the current requirement may be inappropriately defaulted to the means to satisfy the last requirement. And so on.

There must be a true north for this enterprise information architecture, and that is provided in this book. I do not provide a one-size-fits-all reference architecture. Each company is going to be different. There are different starting points and different target interim ending points for architecture (it never really ends). Each company is at a different level of maturity and will wish to advance at a different pace. Many companies are not going to be able to move at the speed desired without new skills in place.

There needs to be a process in every organization to vet practices and ideas that accumulate in the industry and the enterprise and assess their applicability to the architecture. I highly advocate some company resources be allocated to looking out and ahead at unfulfilled, and often unspoken, information management requirements and, as importantly, at what the vendor marketplace is offering. This is a job without boundaries of budget and deadlines, yet still grounded in the reality that ultimately these factors will be in place. It's a very important job for caretaking the information management asset of an organization. For titles, I'll use chief information architect.

The chief information architect

The information architecture in place at any point in time is going to be a combination of a bottom-up, needs- and workload-based approach and a top-down, longer-term, thought-out approach. Bottom-up solves crises and advances tactical needs. Top-down -- the job of the aforementioned chief information architect among others -- looks ahead. It still solves tactical issues, but does so with the strategic needs of the organization in mind. While no organization is run by either approach exclusively, can we please dial up some more top-down to avoid problems caused, essentially, by the lack of a true architecture?

The proposed approach of this book is that organizations should take the following steps:

1. Have a "true north" in mind for a five-year information architecture, understanding that it is subject to change.

2. Have a chief information architect managing the five-year plan and contributing to workload architecture.

3. Organize new information requirements into workloads, which comprise functionality that is necessary to achieve with data, as well as the management of the data itself.

4. Allocate those workloads to the most appropriate architectural construct for its success (defined below).

5. Perform all work with an eye towards delivering return on investment (ROI) to the business at the lowest total cost of ownership (TCO).

Information workloads

Allocation of workload to an architecture component is both an art and a science. There are user communities with a list of requirements on a set of data. There are other user communities with their own list of requirements on the same data. Is this one workload? If ultimately it is best to store the data in one location and utilize the same tool(s) to satisfy the requirements, the practical answer is yes.

Ultimately, we are trying to deliver ROI to the business. It's a principle well worth following as you make decisions. [Return on investment] is found by dividing return by return minus investment, expressed as a percentage, and is always specified with a time period (e.g., 145% in three years). It requires the discipline of breaking down the workload into its projected cash flow. Whether you embrace the math or not, embrace the idea of delivering value to the business that could ultimately deliver ROI. This can happen through short-term financial-bottom-line impact or through information-borne innovation that yields ROI later. That is what information management should be all about -- not speculation, fun exploration or a book standard. It's about business.

Once we have established, as a business, that a workload has high, positive ROI (relative to other possibilities for the investment), we establish the architecture for it that meets the performance, agile and scalability requirements with the lowest TCO. As such, most of this book is focused on conveying the capabilities of each platform to help you allocate workloads appropriately -- with the lowest TCO! It is not designed to make you a "one percenter" in knowledge of any of the individual platforms in isolation.

Copyright information

This excerpt is from the book Information Management: Strategies for Gaining a Competitive Advantage with Data, by William McKnight. Published by Morgan Kaufmann Publishers, Waltham, Mass. ISBN 9780124080560. Copyright 2014, Elsevier BV. To download the full book for 25% off the list price until the end of 2014, visit the Elsevier store and use the discount code PBTY14.

What determines workload success

It is primarily the performance of the data access that constitutes the success of a workload. Performance can be engineered (and it always must be to some degree), but primarily we give performance a huge step forward with correct workload-platform allocation.

Secondly, we need to get the workload up and running quickly. Getting to that fast performance quickly is the second measure of the success of an information workload. I talk about Agile methods in Chapter 16.

Thirdly, if the good performance goes away quickly because the application is not scaling, all would be for naught. The third measure of workload success is scale. The solution should be scalable in both performance capacity and incremental data-volume growth. The solution should scale in a near-linear fashion and allow for growth in data size, the number of concurrent users and the complexity of queries. Understanding hardware and software requirements for such growth is paramount.

Note that this does not mean the initial architecture will last forever, untouched. All good things come to an end and information management is no different. This does not stop us from pursuing making information as good as it can be, given what is known today.

These are the three factors I primarily consider as I give workload recommendations for the various information management platforms in this book. It does not mean there are not other factors. There are, but they tend to be "dragged along" when the focus is on these three factors. Architecture component selection is more important than ever because it must scale with exponentially increasing data volumes and user requirements.

To read a Q&A with William McKnight on some of the topics addressed in his book, click here.

Email us at and follow us on Twitter: @sDataManagement.

Next Steps

Analytic and operational jobs both headed to be cloud workloads

Dig Deeper on Enterprise data architecture best practices

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.