Why blog?

There aren't many Data Architecture blogs. I have struggled to find data architecture related information. A lot of the available information is ambiguous, hard to digest, or theoretical. Information is often presented as a one size fits all with few implementation details. Simply question does it add value? - if not don't do it!

Objective
  • Provide information that is useful to others
  • Provide information in a format that can be easily understood
  • Provide an understanding what a Data Architect does
  • Engage with people interested in Architecture and Data Management
  • Don't blog about topics that are already well covered
Me
  • I'm passionate about data, technology and design.
  • I'm technology agnostic. I view technology as tool-set and base selection on skills, fit, cost, time.
  • I like to solve problems. It is very satisfying coming up with solutions for problems of any size.
  • I like to help others; mentoring, training, discussion, advice etc.
My principals
  • Design is key - Do as much as possible before build commences, modify as required rather than work-around.
  • Question the bigger picture - how will this project help the business, what is planned for the future, can the solution be extended / re-used, who is going to maintain this following delivery etc.
  • Be pragmatic - if the business gets the majority of value from 20% of the solution then focus on delivering that first.
  • Compromise where applicable - no point focusing on delivering a purist solution, but is unnecessarily difficult to code and maintain.
  • Hold your hands-up if something doesn't work - no point belligerently continuing an idea to avoid losing face.
Disclaimer
The information contained within the blog is my own personal view and not a reflection of the business I currently work at or any business that I have worked at in the past.