Building a strong Data Management capability with TOGAF and ArchiMate
•
35 gostaram•11,433 visualizações
This is the deck that I used for my presentation at the EAM conference in 2013. It gives a high-level overview of the need for a solid data management capability before giving and overview of how enterprise architecture methods can be used to build this capability.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (20)
Semelhante a Building a strong Data Management capability with TOGAF and ArchiMate
Semelhante a Building a strong Data Management capability with TOGAF and ArchiMate (20)
Mais de Bas van Gils
Último
Último (20)
Building a strong Data Management capability with TOGAF and ArchiMate
- 1. Building a strong data management capability with TOGAF® and ArchiMate®
- 2. Dr. Bas van Gils 2 +31-(0)6-484 320 88 b.vangils@bizzdesign.nl http://linkedin.com/in/basvg http://blog.bizzdesign.com http://www.twitter.com/basvg “Life is and will ever remain an equation incapable of solution, but it contains certain known factors.” --Nikola Tesla (1935)
- 3. Agenda • Why data management matters • Setting the scene: – Introduction TOGAF – Introduction ArchiMate • Using TOGAF and ArchiMate as instruments to build a strong data management capability • More information Comicsfrom:http://www.datagovernance.com
- 4. WHY DATA MANAGEMENT MATTERS
- 5. Does this sound familiar? Delivering answers to an intelligence question takes several days. We need the answer today! We do not have a single, unified view of our customer or our products We don’t trust our intelligence data. Quality has been an issue too often in the past. Tracing customer complaints, late orders, defective parts is extremely hard for us
- 6. 6 Data Management: NoSQL, Big Data, BI, Business Policy / Rules, MDM, Meta-data, Data Warenhouse Strategic Management: Business Model Canvas, Innovation, Business Intelligence, business model
- 7. Data as an asset - Jill Dyché, IRM UK 2013 MDM/DG keynote “Big Data and Data Asset Management”
- 8. Map out the enterprise [Master] Data Management programs cause change: to data, to systems, to business process, to people and to the enterprise. An organization should map out their organization to identify the data, systems, process and people affected by the initiative and how they will be affected. -- Whitepaper “Why MDM projects fail and what this means for big data” by Entity
- 9. INTRODUCTION TOGAF AND ARCHIMATE
- 10. Ingredients of an EA framework 10 View- points Repository, Reference Models Process Language ArchiMateTOGAF
- 13. Applying ArchiMate® 2.0 Baseline Target 13
- 14. USING TOGAF AND ARCHIMATE AS INSTRUMENTS TO BUILD A STRONG DATA MANAGEMENT CAPABILITY
- 15. Framework for Data Management • Many frameworks have been proposed for DM – Focus on an aspect of DM – Focus on tooling for DM – Focus on a process for DM – ... • This presentation is based on the DAMA DMBOK framework – Integrated approach to DM – Easy to align with the OpenGroup standards for Enterprise Architecture
- 16. Building a DM capability using EA methods TOGAF provides a structured method for effectively realizing a business vision: • start with a business vision for the data management capbility • develop baseline & target architecture • incremental realization Capability based planning is a key ingredient for succesful enterprise-wide change • DMBOK Elements map on aspects of the DM capability • Provides a basis for roadmapping: what goes first? ArchiMate is the language of choice for enterprise-level modeling • High level modeling within & across domains • Basis for analysis & visualization • Aligned with TOGAF & DMBOK
- 17. Data governance • Integral, enterprise wide governance is key to success • The role of the data steward is crucial: s/he is responsible for data quality in a specific subject area • Data stewards co-ordinate their work in a data council which is jointly responsible for the information landscape
- 18. Information versus data • Several Entities are pertinent in the context of a Subject Area • Several systems may manage Data Objects that realize (part of) the information that is pertinent to these Entities • In terms of decomposition: – At the architecture level we work with Business Objects and Data Objects – These may be refined in an ERD diagram at the design level
- 19. Master Data Management (MDM) • Many organizations have to juggle with disparate administrations of key entities • Having an integral overview of these entities is key to business success • MDM is the discipline of providing this integrated view. There are many (IT) patterns to realize this goal. In modern architectures it often ties in with SOA
- 20. Business Intelligence & Data Warehousing • Transaction systems directly supporting business processes maintain data at a low level of granularity • Business Intelligence is a query, analysis, and reporting capability of the organization that provides insight in historical and aggregated data of the organization • A data warehouse (EDW) is a technical environment that enables Business Intelligence
- 21. Meta-data management • Meta-data is often defined as “data about data”. • A distinction must be made between – Business meta-data – Technical meta-data • Everything that we model about data can be seen as meta-data: – Properties – Documentation – Relations to other objects
- 22. Overview Stewardship of an information area Decomposition of an information area in entities Mastering of data objects in an MDM environment Data movement to an EDW environment for BI products such as financial reports, production reports, governance logs etc.Data Object counterparts of entities are stored in information systems
- 24. Alignment with the business, strong data governance, and grip on the information landscape enables the organization to get answers quicker. Master Data Management (MDM) helps the organization to define a single unified view of key Entities Central meta data management (business definitions, links to processes, lineage in systems) and strong governance results in increased trust in data quality. Data issues often lurk under business issues. A model-based approach covering all related enterprise- issues will enable the organization to handle these issues effectively Problem solved? Delivering answers to an intelligence question takes several days. We need the answer today! We do not have a single, unified view of our customer or our products We don’t trust our intelligence data. Quality has been an issue too often in the past. Tracing customer complaints, late orders, defective parts is extremely hard for us
- 25. Both the information landscape, system landscape, and organization / governance structure around data management are highly complex. This complexity is managed by using ArchiMate modeling with BiZZdesign Architect Take Away Data management is not a project; it is a continuous process. This capability will contribute to sustainable business success. An architecture-approach will help the organization to build a strong data management capability. Organizations are increasingly dependent on quality data / information to run their business. Therefore: data management is a business issue.
- 26. ©BiZZdesign. All rights reserved. BiZZdesign and BiZZdesign logos are registered trademarks of BiZZdesign Company.
Notas do Editor
- This slide (and the next) appeal to BiZZdesign’s vision on using open approach: don’t re-invent the wheel but use what is already there. DAMA = DAta Management AssociationDMBOK = Data Management BOdy of KnowledgeThis framework is broad and descriptive. It can be used as a reference model to help (a) standardize terminology, (b) decide which parts to implement in the organization, and so on. There is some talk online of TOGAF and DMBOK getting more and more aligned. Another reason for going down that road.
- Slide 8 was our proposition. That’s the “what” part. This slide is the “how” part. In order to help build a strong DM capability we use 3 ingredients:TOGAF: provides the general frame. Start with a vision, build a model of where we are (baseline) and where we want to be (target) and find a way to get there several steps. Implementation governance keeps us on track (stay aligned with business vision)CBP is one of the techniques from TOGAF. In the early phases (vision mostly) we figure out the current level of capbility along the elements of the DMBOK framework: how good is our process? how good are our tools? our people? This also helps to establish the desired increment which drives the initiative. Note: Dick made a first version of tool-support for CBP!For everything that relates to modeling at the enterprise level, we’ll use ArchiMate. When discussing this, be sure to mention that detailed models (ERD, UML) may still be necessary. We’re working on ERD support
- We’re now diving into a set of ArchiMate-styled diagrams with extra eye-candy. For now that is all powerpoint. At some point we will actually have to build similar visuals in the tool. When presenting, point out that these are all views on an integral model. We’re starting with governance and linking it to the other aspects.The data council is a key group of people in the organization – at least from a data perspective. A steward (modeled as a business role in ArchiMate) is responsible from a business perspective for the information in a specific information area (see the work of James Martin). Stewards talk to their IT-counterparts and together they figure out the best way of realizing data requirements.
- Next step: build the bridge to IT. This is where the strength of ArchiMate kicks in: Entities (modeled as BusinessObjects) are realized in various places in the IT landscape. A common source of data quality (DQ) issues is mis-match in data definitions when building IT systems. This is inherent to the way we build our systems: write up requirements, and design a system specific to those requirements without looking at the bigger picture.Stress another strength of ArchiMate here: this is the perfect spot for building and maintaining a conceptual data model (enterprise data model) that can be re-used across IT implementation projects
- With many manifestations of a business entity in the application landscape, there is often a need for an integral view of key entities. Typically customers, products and components, etc. MDM (Master Data Management) is about creating a golden record, a single version of the truth. There are many architectures for achieving this (system of record / system of reference, using a service oriented approach, etc)There are many levels for modeling MDM, such as:which data objects are used for the creation of a golden record that’s visualized herewhich attributes of DO’s are used in the golden record how data flows into an MDM system etc.
- Another interesting topic in this field is BI and DW. This is an area that is typically associated with a lot of specialist modeling techniques such as:data vaultsnowflakestarschemaetc.At the enterprise level we tend to keep things at a higher level. The actual details of staging and data transformations in the EDW are not relevant here. From an enterprise perspective it is useful to see the lineage of data: how does data flow through the application landscape and end up in BI products. Here we can see how the EDW takes data from the MDM environment (which is integrated, and most likely cleansed) as well as the ERP system. More detailed analysis up to the attribute level is possible if necessary.
- Metadata management is a big discipline. Meta-data is every where:business metadata says something about stewardship, definitions, quality, where data is used etc.technical metadata says something about column definitions, field specifications etc. in the IT systemnote that there’s also specific metadata for things like BI and MDM. Here we see a subset of the metadata about the Customer entity in the middle:the stewardprocesses that it is involved in (as a label view)data quality requirementsmanifestations in the IT landscape including an indication of which one is the golden record
- In this slide I’ve attempted to bring together part of the details from the previous slides. Don’t go over all the details again. Instead, explain the strength of ArchiMate: integral modeling within a domain as well as across domains. Also emphasize the fact that the fact that this is a formal model helps in doing all sorts of analysis (impact of change, analyze damages and so on).
- Not all clients will want to see this. Keep it handy when someone asks: this shows the formal metamodel for doing DM with ArchiMate. On the left is a predicate model (visualized as an ORM diagram), on the right is its ArchiMate counterpart.