Logistics

  • 27 May 2022
  • J.J. Du Chateau, University of Wisconsin-Madison
  • Louis King, Yale University
  • Piet Niederhausen, University of Washington
  • Slides > Presentation Deck <

Context

  • DAMA Framework provides a useful frame of reference, separating data governance  and data management  like this:
  • One challenge at our institutions is that data governance tends to come in after all the other behaviors in the DAMA wheel are already underway everywhere.
  • Another challenge is that higher-education institutions are very distributed in terms of accountability and organizational structure and domain, illustrated in this diagram from Louis King:
  • As architects, how we engage with this space requires us to be aware of complexity of these activities in our institutions — this constitutes a "wicked problem", a problem that is difficult of impossible to solve because of incomplete, contradictory, and changing requirements that are often difficult to recognize.  There are both complicated and complex aspects of data governance and data management.  The nature of this demands an evolutionary/iterative approach to data governance and data management (particularly in large and complex organizations).
  • Although this is wicked for all of its complication and complexity, we can "chunk" our approaches using the DAMA framework above and by navigating the overall space in partitions (e.g., by organizational unit or data domain).
  • Architecture is a practice that can apply a design mindset (and enterprise architecture takes an organizationally-holistic approach) and can work iteratively, and the role of architecture isn't so much in question here as at the very core of what our practices must do and lead and influence.
  • Our responses will be different in one architecture domain (e.g., technical architecture = identifying capabilities in the underling IT solutions) than another (e.g., business architecture = understanding which business capabilities are implicated in a certain data-governance-and-data-management "slice").

Lifecycle Considerations

Plan and Design

Through the lifecycle, "plan and design" will focus upon data architecture and data modeling and design in the DAMA wheel, concentrating on understanding how data will be used and what integrations are required across the various perspectives:

  • EA and TA: create maps and landscapes of which applications are creating or consuming the data
  • BA: capture, harmonize, and communicate the semantics behind data elements in different systems and different contexts.
  • BA: identify opportunities to meet common needs by generalizing the solutions and approaches taken to designing and caring for the data.
  • BA: architects bring is the Customer Experience / Customer Journey lens (e.g., "what data do i need to do my job?").
  • EA: part of the responsibilities for taking a holistic approach includes unifying the architecture approach end-to-end across the various architecture-perspective domains.
  • EA: ensure appropriate authorities are in place to avoid or help manage/reduce "data sprawl" and ensure there are appropriate data-sharing arrangements (or at least data-sharing awareness) in place.
  • Northeast Community College is taking a business-capability-led approach that focuses on the data, rather than the applications, to understand the data estate through the lens of the functioning enterprise.
  • There probably is a role for architects (perhaps for data architects in particular) to be considering in the plan-and-design phase future-lifecycle aspects such as data lineage and data provenance.  This is a more-sophisticated aspect of what needs to be considered when designing enterprise data flows (either raw application-layer integration or into a data warehouse, etc).

Foundational Activities

Through the lifecycle, "foundational activities" will focus upon data quality and metadata (management) and data security in the DAMA wheel.

  • Here, architects need to consider aspects of the compliance environment too (e.g., what are your obligations under GDPR and other privacy-related regulations?).
  • Think about bringing and representing the views of the people who will use or be affected by how the data are presented and cared for, show the experiences that result from data governance decisions.
  • Architects must also help navigate the implications of data governance decision upon the solution space (e.g., making the decision that certain attributes in a payroll must always be treated as highly-sensitive opens a bunch of requirements that the underpinning applications and technical services might not be well-positioned to fulfil without significant and costly modifications) — at a higher level, there is also a role here for architects to inform and explain the implications of institutional policy changes.
  • Architects encountering data governance and data management in their work and needing to make decisions on a situation-by-situation basis should be applying architecture thinking and "harvesting" common approaches to bake into something like a body-of-knowledge or a collection of data standards that are reusable by others, helping to amplify these approaches across the broader institution.
  • Information Architects would have a strong role to play in "show me what applications contain this data" by holding maps of the data and the relationships between the data types and knowing where the data are stored and how they are used — holding this information set somewhere accessible and central and unified is important, as each application will have its own data structures and data semantics and data flow requirements, all expressed in different ways, and there are lots of applications out there!

Enhance and Use

Through the lifecycle, enhance and use" will focus upon everything else in the DAMA wheel: data storage and interoperability, document and content management, reference and master data, and data warehousing and business intelligence:

  • Data will often end up in a data warehouse and be used for various types of reporting and visualization
  • Architects will need to foster greater data literacy within their institutions, and educate users not only on practical matters such as data flows between applications but also on the implications of data quality and data sharing.

Oversight

Tying everything together, data governance concerns the authority and control over data management activities, and there is much here that architects must consider, such as:

  • bridging the cap between the intent of data governance and its manifestation in the underlying technical capabilities
  • sustaining the investment in and focus upon data governance (adding that "flywheel" inertia to the enterprise)
  • anchoring and navigating data-related issues with the risk management and senior leadership functions to ensure appropriate awareness and accountability

Further Information

Resources

Participants

ZOOM Chat

06:03:38 From  Curtis Scheer  to  Everyone:
    Welcome to the call.   I'm new to EA as well same situation new to me and new to my organization
06:07:20 From  J.J. Du Chateau   to  Everyone:
    Did I move Piet?  :)
06:07:52 From  Curtis Scheer  to  Everyone:
    can we have a link to the slide deck?
06:08:11 From  Louis King  to  Everyone:
    https://docs.google.com/presentation/d/1QbtB3izAlDIRaUBIF4xAQ_4BK4a3Lcx4F90R6DqeawM/edit#slide=id.g12e760a3d0a_1_97
06:08:22 From  Curtis Scheer  to  Everyone:
    Thanks!
06:08:38 From  J.J. Du Chateau   to  Everyone:
    Links and meeting notes will also by on Itana.org at some point in the near future.
06:13:55 From  Mary Stevens  to  Everyone:
    Does wicked align with the Cynefin idea of complex?
06:14:10 From  Piet Niederhausen  to  Everyone:
    Complex or possibly even chaotic ... your choice : )
06:17:36 From  Jim Phelps  to  Everyone:
    I think another lens that architects bring is the Customer Experience / Journey lens.  We can talk about what is it like for institutional reporting, integrators, etc when they want to get access to data
06:18:25 From  jeff kennedy  to  Everyone:
    ...and Information Architecture?
06:18:36 From  Piet Niederhausen  to  Everyone:
    Both great analytical approaches to bring to DG/DM!
06:21:21 From  J.J. Du Chateau   to  Everyone:
    Yes Jeff,  Other arch types are what we'd like to hear example about too.
06:25:52 From  Curtis Scheer  to  Everyone:
    Here is a great graphic along those lines - https://www.leanix.net/hubfs/Blog/enterprise%20architect%20vs%20solution%20architect%20vs%20technical%20architect.png
06:33:21 From  Louis King  to  Everyone:
    Mahmoud, I totally agree in regard to the provenance.
06:47:29 From  Mary Stevens  to  Everyone:
    +1 to JJ, it may not exist now.
06:54:49 From  Curtis Scheer  to  Everyone:
    i would add to that in addition to having access we are also working towards data democratization
06:56:38 From  Louis King  to  Everyone:
    Curtis, interesting, we helped establish an open access policy to Yale’s cultural heritage content in the public domain. It was a powerful paradigm switch.
07:00:42 From  Russell Connacher  to  Everyone:
    Great discussion all.
07:00:50 From  Russell Connacher  to  Everyone:
    I need to drop off
07:01:18 From  Andrew Frank  to  Everyone:
    I need to drop as well, this was a lot of fun - thanks everyone
07:01:34 From  Ashish Pandit  to  Everyone:
    Need to drop off. Thank you
07:02:00 From  Lisa  to  Everyone:
    thanks for letting me join in, amazing discussion!
07:02:11 From  Louis King  to  Everyone:
    Thanks Piet. That was great!
07:02:20 From  Louis King  to  Everyone:
    Thanks JJ.



  • No labels