I am seeking to increase my specialty of knowledge and skills around Product Deliver and Management from a Data Architecture perspective. Meaning, I want to be able to advise, consult my peers and organization on Data Architecture best practices for our clients product go to market strategy. Any suggestions of Dataversity classes or knowledge sharing?
Catriona Hillhouse, MBCS CITP
I'm afraid I have no advice or suggestions for you but I am at a similar stage and am interested to see what more helpful, replies you might receive.
Sonya A McNeal
I have been talking more with my peers on what services they are seeking. Basically, best practices around Data Architecture especially in the Salesforce Ecosystem. So I am putting together a process document as a first iteration and go from there in how it will be used and changes needed over time. Modern Data Architecture is needed for Go-to-Market product management for Cloud platforms. I am hoping to gain some more expertise, knowledge and materials that we can share and learn from in the future. Hopefully, we can network through this forum by sharing information and interests.
Sonya A McNeal
“Believe in yourself. You are braver than you think, more talented than you
know, and capable of more than you imagine.” ― Roy T. Bennett
Sonya A. McNeal,
Principal Data Consultant
STRM Consulting, LLC
On Sun, Oct 6, 2019, 2:51 PM Michelle Knight <
[login to unmask email]> wrote:
> This is an area that sounds interesting and I will let you know what I
> find that is new.
> Try this article
> https://www.dataversity.net/2019-full-scale-schema-modeling as a start
> on at least Data Architecture schemas. It includes recommendations with
> solution and physical business orientation.
> -----End Original Message-----
I think the biggest challenge is understanding and defining what a "data architecture" is - because that term means many different things to different people and depends heavily on the background/experience of the individual and the goals they are trying to meet. For example, I take an Enterprise Architecture view of Data Architecture, so it is just one of many complementary views of the system I am considering (alongside, for example, software architecture, hardware architecture, and business process architecture.) With this perspective, the Data Architecture is JUST about relationships among data and data assets - it is NOT about access, software, security, or quality (each of which are handled by other architectural views, which do relate to the data architecture but are not part of it. (i.e., Stay In Your Lane! :-) ))
william burkett[All DATAVERSITY Members] @ Oct 07, 2019 - 11:03 AM (America/Mountain)
Agreed that data architecture can mean different things to different people.
The definition in DATAVERSITY views data architecture as the implementation of data strategy and a bridge between business strategy and technical execution. Where a lot of organizations view and wish to use data as an asset, data architecture needs to consider all the physical components that define data, including relationships among data and data assets. The definition here considers that and synthesizes the components into outcomes, activities, and behaviors.
Donna Burbank, an information management expert has done a webinar on Enterprise Architecture vs Data Architecture and I have uploaded the image here. I hope that helps.
I don't disagree with what you've said here, Michelle, nor do I disagree with what you've said on the "What is Data Architecture?" page (though I do disagree with some of the data architecture elements illustrated that are identified as part of a data architecture.) However, it is hard to envision what a data architecture actually is from that definition.
For example: "as the implementation of data strategy and a bridge between business strategy and technical execution" is a nice strategic description of the role of a data architecture, but doesn't tell me what it is. Similarly: “includes specifications used to describe existing state, define data requirements, guide data integration, and control data assets as put forth in a data strategy.” identifies some of the things that are "in" a data architecture and (some of) what it does ... but doesn't tell me what it is. (I apologize for the pedantry over definitions - I've been a data modeller for many years and have grown to be evangelical about the value of good definitions.) And I stress again that I don't disagree with those quoted statements - I just don't think they're enough. I do think you've made an important distinction, though, between a data architecture as a thing (outcomes) and data architecture as a practice (activities and behaviors).
I think I attended Donna's presentation, but as I recall that was part of a series of webinars and my attention may have been divided between it and work. Looking at the image you attached to the message (which I assume is from Donna's presentation?), I see it as a kind of loose data management architecture diagram, but it isn't clear from this image alone how it relates to Enterprise Architecture.
I guess my bottom line is that I see/hear a lot of high-level descriptions of what data architectures are supposed do and things that need to be considered when creating one (which all sound good), but I wouldn't know how to take the first step in creating one based on what I've seen/heard. (I'm exaggerating a little bit, of course, but I hope you get my point.)
I am hearing you say that "data architecture" is something someone can point to and say it is that. As you wisely noted it can be very difficult to define data architecture because of different backgrounds, experiences, and company goals. The definition, from the Data Management Body of Knowledge (DMBOK) and displayed on the What is Data Architecture comes from an acknowledging any architecture is an art and science and organizational data can be represented by multiple levels of abstraction, of which Enterprise Architecture is one facet. Keith Foote has a concrete definition, that data architecture is a set of rules, policies, and models that determine what kind of data gets collected, and how it gets used, processed, and stored within a database system. But that may still seem rather abstract because that picture/s looks different across different organizations.
I think the specific data architecture conception/s comes out of data management and the form of this/these depends on the business priorities as specified by the business priorities and data governance. This is where Donna’s chart comes in handy. It shows Data Architecture and Modeling as tool/tools leveraging the data to make a business competitive from business and data strategies and as informed by data governance. Slides on where Enterprise Architecture comes in can be found here. See slide 6.
The most detailed data architecture, Data Management Body of Knowledge (DMBOK) describes, is a formal enterprise data model, containing data names, comprehensive data and Metadata definitions conceptual and logical entities that and relationships. I think for some organizations that may work just fine, but it may seem like not enough to other firms that carry out different levels of Data Architecture.
The best thing to look at is data architecture outcomes, activities, and behaviors. Think of it this way. A residential house and an amusement park are both architectures but look very different. We know that outcomes, activities, and behaviors have differences in both is determined by the larger business goal. I tend to think similarly. I do appreciate your insights and welcome opening up a larger topic to hear additional insights.
Maybe clarifying data architecture should be its own topic in the forum to include your's and other's backgrounds and experiences in defining data architecture?
Thank you for taking the time for the thorough response, Michelle. And for indulging and considering my "soapboxing".
You are totally right that different definitions of "data architectures" lead to different realizations of a "data architecture". I am not about to say any of these are "wrong." I do think, however, that it behooves us as data management professionals to continue to refine our vision and craft and move the mission of DAMA and the DM-BOK forward. So while the various realizations of data architectures are not "wrong", they are (obviously) inconsistent, which in the long run are not in our (data management professionals) best interests. Data architecture is a design engineering task; "craft" is a better term than "art" and the science is systems science (with a splash of computer science database theory).
I do think a data architecture is structured assembly of many different kinds of models, as is defined in the DM-BOK, and the rules and policies governing this assembly of models. Contrary to your citation of Keith Foote's definition, I feel strongly that "what kind of data gets collected" and "how it gets used, processed..." are not part of data architecture (they are parts of business process architecture and/or software architecture).
Coming back to the Enterprise Architecture theme and your residential house and amusement park example, while what you've said about them is true consider the blueprints/engineering drawing that govern the construction of those facilities. They are separated into distinct architectural views: structural, electrical, plumbing, HVAC. Each of them have a distinct purpose to the builder who is implementing them, and each must be coordinated with the other so that they don't step on each other's toes. But you would not expect to see a hot water heater on an electrical diagram except as a touchpoint to the electricity it needs. Similarly, "how data gets collected" shouldn't be part of a data architecture except as a touchpoint between the data architecture and the business process (or software) architecture. And the desired outcomes are extremely important and are part of a goal or requirements architecture, which is satisfied by the design decisions made about the data (and software and business and hardware) architecture.
Thanks for the conversation. If there is a better place to discuss it, I'm happy to go there and continue the conversation.
I think it is worth keeping this conversation going so that managers and organizations know what to expect when they hire a data architect. I think you are saying that components associated with data architecture are more than not being muddied with that of a software architect or business process architect. So, I started a new thread here. Let us keep the conversation going there and let me know if you have any additional suggestions.
"components associated with data architecture are more than not being muddied with that of a software architect or business process architect. "
Yes, that's exactly what I'm saying, Michelle. (Or an important part of it, anyway.) Rather than respond further here, I'll take the conversation to the new thread.