When you document the business architecture, you describe business activities as well as the information (data) flow among the activities—what information does an activity generate, what does it receive from and send to others. You should identify the information—I'm going to call it "data" from now on—at an aggregate level such as order, invoice, contract, project, account, book, employee, and so on. In other words, you are not trying to define the details of the data; it's just an aggregate data entity. The aggregate data entities typically represent some real-world entities. One detail that's important to capture is how the data is used by specific business activities, by using a notation called CRUD—create, read (or retrieve), update, delete—that indicates what each activity does with a specific data entity. You can then construct a CRUD matrix that shows data use by business activities. A CRUD matrix is simply a table with columns of data entities and rows of business activities where each entry shows (using the acronyms C, R, U, and D) what a business activity does with a data entity. Here's a simple example of a CRUD matrix:
Customer Order Product Invoice Set up account CRU Enter order RU CRU R Fulfill order R RU RU C
The high-level view of all data helps you figure out how to logically group the data into specific data stores (databases) and ensure that the same data is not duplicated in multiple databases. You don't have to develop entity-relationship diagrams (ERD) for the high-level data architecture. The ERD step comes next when you want to develop the data models. You can use one of many tools available for data modeling. Just Google data modeling tool and you'll see what I mean.
Tags: Enterprise Architecture EA architecture data model datamodel CRUD ERD
Comments