However, in many cases the data exchanged between architectural entities is rather complex. For example, in healthcare scenarios complex structures with patient information or charging information are the rule. Not dealing with data as first class citizens might lead to various issues such as versioning problems, or inadequate partitioning or aggregation of data. Thus, architects should deal with data modelling very soon if they are facing complex structures in their development projects.
Data modelling starts with the domain model. What are the main entities in your problem domain and which kind of data do they need to persist, share, or transfer?
Then in the next "layer" when we are introducing the subsystems we'll have to think about data structures in subsystems and data structures exchanged between subsystems. For example, what exactly are the data structures required in the functional interfaces. Obviously, these data structures can be partially derived from the domain model with further data structures required by infrastructural entities or non-functional qualities.
In the component layer we are starting to deal with finer grained data types.
Last but not least we'll have to define how data is mapped to implementation artifacts.
Thus, we should also follow a top-down approach for data modelling. And likewise we need to consider bottom-up constraints such as special data requirements of infrastructures or platforms. With other words, data modelling must go hand in hand with all the other architectural modelling activities:
Important questions to ask when modelling data:
- Who is the originator of data?
- Who is the consumer of data?
- How does data move from the originator to the consumers?
- Do we need to collect/aggregate data from different sources (transfer objects)?
- What about quality constraints such as performance (e.g., caching data), security (e.g., encrypting data), modifiability (e.g., versioning data), concurrency (e.g., locking data), availability and reliability (e.g., replicating data, data persistence)?
- Where and how is data stored?
- How do different data structures depend/relate?
I think, data modelling is an underestimated and undervalued activity in architecture design. What about your experiences and opinions?
2 comments:
As you say most modelling is very focucused on the behavior/functionality and the importnat questions you state are in my opinion seldom answered. When designing a system comes to specifying collaborations between classes and components the interfaces starts to evolve. However, i think, that many architects and developers may not iterate suficiently on the details of the parameters (i.e. the data) for each method in the interface. This tend to be a question to solve later. It would be good to have performed a data modelling session (based on the problem domain) resulting in a data view, that act as an input to the collaborations/interface specifications. Also in UML the data modelling possibilities are not enlighted. Maybe the data modelling techniques somehow got lost when UML was growing large?
i completely agree with your thoughts, in fact having experienced what you just mentioned made me put down my thoughts in the following article :
http://www.ibm.com/developerworks/rational/library/centralized-systems-model-rational-harmony-2/index.html
Post a Comment