DSI
I have signed up to do a Dynamic Systems Initiative talk in about a months time and so have been doing some more in depth research into this area.
DSI is all about system operation and administration and effectively has three levels, a base metamodel called the System Definition Model SDM , and two set of tools; Development and Operations. Additionally there is then a set of processes above this which are defined by Microsoft Operational Framework (MOF), which is an implementation of ITIL in the Operational Space or Microsoft Solutions Framework (MSF) in the Development arena. Both of these could be thought of as part of COBIT which is a very high level set of processes for IT which I quite like as a structure but don’t particularly agree with the specifics.
So that is a quick run through operations from top to bottom. Generally with these things I start at the bottom and look at the data structures to see how the technologies and processes are supported which actually seems to be a fairly good general architectural principle. That is to start the design based on the data or information structures rather than the middle tier or UI.
This is certainly different from the way that most people in MS do design which normally starts at the UI (e.g. use cases). Whilst this can be a useful approach in some specific instances I think that the general case best design point is from the data schemas. In fact I think I will make that Platt’s fourth law:
In general the architecture of a system should start with the data or informational schemas.
Anyway I digress, back on DSI I looked for the SDM schema and couldn’t find anything on any public site so I had a look on some of the internal shares to find the SMD schema. It didn’t immediately strike me as the way I would design an operational schema so I will have to go and think about it in more detail. Meanwhile of course there is a lot in the technology and tools associated with DSI which is published and very interesting, particularly the integration with the design tools space (Whitehorse).
As a matter of interest where would you start to architect a system; top, bottom or middle?
Comments
- Anonymous
March 22, 2004
Well, the UI is just representation of the data, so the two are inextricably linked. However, a general UI can be constructed without the exact data schema. So not at the top.
The database should really be subservient to the business rules, which are often highly illogical. So I generally rule out bottom-up.
That leaves the middle tier. Of course all of this is iterative, so things that people notice later on can affect all three tiers, but in general I start with the business process and business objects, then decide what data schema and UI best represents that. - Anonymous
March 23, 2004
Your question is fundamentally flawed because it assumes facts not in evidence (i.e. you can't know at the start whether there will be a top, middle, or bottom). When you begin to plan or design the construction of a system, you must look first at the current environment (existing systems, processes, etc.), the purpose of the new system, and the needs of the beneficiaries of the new system (users, customers, and other stakeholders). The system architect's job is to create a plan for building a workable solution for balancing the varying forces in that equation. Defining the start of the architect's effort anywhere else just seems very wrong to me.