Page 14
Page 15
Database strategy is essentially a strategy of
which database technology(s) to use for various
enterprise data requirements, e.g., operational
system data, data warehouse, etc. This is driven
mostly by type of data, existing enterprise
technology stack, relation with vendors and
alignment of enterprise data requirements with
vendor software roadmap.
To be clear, if I am to come up with an enter-
prise database strategy, then my first thought
would be “what is it that I am trying to achieve.”
That is, what kind of data am I planning to
support, do the operational systems have any
specific database requirements, how many con-
current queries am I planning to support in my
data warehouse, etc.
My next thought is how to fit whatever I am
trying to achieve with the existing technol-
ogy stack, if any. For example, I don’t want to
use, say, postgresql database with applications
written in .Net framework. Sure it will work, but
it is not the best possible combination. In .Net
world, MS SQL server is always the 1st class
citizen as is DB2 in IBM world.
Next, I would have to look at the vendors’ tech-
nology roadmap and make sure that for a long
term, my data requirements will be supported.
For example, if I am expecting my data volumes
to multiply by 50 times in the next 2–5 years,
will my DBMS software support it?
And finally, lastly but very importantly, how is
my relationship with the database technology
vendor? Are they responsive to my support que-
ries, are they willing to give me a good deal, can
I bank on them in case of a major screw up?
Data strategy is rather tricky, but here is a shot
at it. An enterprise data strategy document
should ideally define 6 things.
1. Type of data supported: I will take the exam-
ple of healthcare industry. If I had to come
up with data strategy for a medium-sized
MCO, I will have to support member, pro-
vider, claims, care management, member/
provider services, marketing, finance and
HCM related data. I have to define an ex-
haustive list of datasets and what data falls
under each type. At this point, I will also have
to think about how these types of data feed
into various business needs.
2. Define source of truth: Once all the types
of data is defined, the next step is to define
the source of truth for each type of data, i.e.,
which source will take precedence in case of
data conflicts. This is sort of the stage where
the operational systems get decided in case
it is a brand new setup or a process redesign
project.
3. Data flows: Once the systems are all defined,
the next step is to define the flow lines in
case of interdependent data. For example,
how will data flow from HCM system to
finance system or from your core operation
system to finance system, or all data from
respective systems to data warehouse? The
flow lines should tell you what data is flow-
ing from where to where, and at what inter-
val. This is where the Master Data Manage-
ment plays a big part.
4. Security Requirements: Now that the data
is all over the place, security strategy has to
be decided in order to adhere to the security
laws, as well as protect your data. Mostly, this
is done by system, by type of data, by user/
user role.
5. Storage Requirements: Although storage is
getting progressively cheaper, appropriate
storage strategy is essential for easy mainte-
nance and to avoid expensive mistakes.
6. Back-up and DR scenarios: Last but not the
least, your storage strategy is only as good as
your back-up strategy.
To conclude, as the names suggest, data strat-
egy is about your enterprise data, irrespective
of technology, etc. The only consideration here
is really your enterprise data requirements. Data
strategy normally trickles down to various other
strategies and database strategy is just one of
them.
-Enterprise Data Strategy & Enterprise Database Strategy-
What Is The Difference?
