It’s My Data and I’ll Do What I Want With It….

February 9, 2015 | ,

A Solution Architect needs to have a clear understanding of a client’s data architecture. Most – if not all – of the projects to which I’ve been assigned have had the movement of data as a key part of the solution. When it comes to data, operating from a “project-only silo” mindset is a recipe for disaster. Understanding what the company’s data architecture is and what role it plays is key to avoid missteps.

In simple terms, data architecture is comprised of the policies and rules that dictate what data is stored, how it is stored and how is it made available to others in the organization. One example of data could be customer information. Let’s assume that your project needs to populate Customer Name and Address on some outgoing correspondence. Usually the first questions you ask are:

  • Where is the data stored?
  • How can I get it?

So you got the answers and you’re all set, right? Not quite. You need to dig deeper. There must be many other applications that use the same data. Check with the enterprise data team (hopefully there is one). It’s possible the data is already stored in a central location which may be the recommended place to get the data such as a Master Data Management data store. Why? Because you do not want to create a new data extract or integration method if the work has already been done by someone else. Leveraging an enterprise approved data store and integration layer will help by:

  • Reusing work already done – especially mapping, confirmation, cleansing, exception handling etc.
  • Allowing the EA team to track who is accessing the data
  • Getting access to any upgrades to the data store or integration methods

See below for one possible view of an enterprise data architecture:

Figure 1: Data Architecture View

 

On the flip side, if the data you need is not currently stored in a master data repository, maybe it should be! Check with the enterprise data team. Your project could be the one that gets that data moved to a centrally located repository which in turn will benefit any future users of the data.

Hopefully this simple example has showed you why data architecture is important. There is a whole discipline around data architecture and I would recommend that any solution architect becomes more familiar with it.

 

The following two tabs change content below.
Jim Sweeney
My LinkedIn profile

Jim Sweeney

is a consultant with Systems Flow, Inc. Over his 25-year IT career, he has worked with some of the largest companies in the financial services and insurance areas. His experience runs from hands-on (Java, C++ and C#) to application and solution architecture. He has led many small and large projects to successful completion, and enjoys working with his business partners to achieve their goals. Jim has a BS from Northeastern University in Management Information Systems and a MS in Computer Science from Boston University. Jim's LinkedIn profile has the whole scoop on who he is and what he's done.


Comments

Comments are closed.