Technical trends: Virtualisation
In an early article I wrote that technology usually is quite irrelevant for achieving the goals of data management, but in some cases there are trends worth noting.
One of the latest trends (or hypes) is Virtualisation - this is a very technical trend, especially in the light of something as non-technical as data management, but it is still interesting. Why? One of the key issues in data management is that users keep their data in files in their local environment. There is all sorts of ways to get a handle on this (e.g. synchronise the local drive with the network, or even better get rid of the local drives all together and introduce Sharepoint team workspaces), but for applications there is still a challenge. People want to run their apps close to their data (think performance).
By moving the applications to a virtual machine (in the data center), than the data in the data center is actually closer to the application, then if it would be on the local drive ... That's worth a thought!
Data Management & Architecture
It is surprising how close Data (or Information) Management and Architecture are to each other. Where Architecture is more technical and Data Management is more about how we handle data / information in processes, there is also a lot in common. Both are strategic and are about changing behaviour, about implementing standards and rules, and both are usually seen as overhead.
Maybe there is merit in bringing Data Mgt and Architecture closer together ... Shouldn't have any large IM&T department a group for Data, Architecture & Strategy?
Labels: architecture, Information Management
Big Choices [2]
When making big architectural choices it helps to do the following:
- define the different areas in which choices can be made (e.g. deployment platform, data & integration, processing, ...)
- for each of the areas define at least two scenarios (preferably these scenarios are black & white, like thin client vs thick client).
- describe the attributes of each scenario. When doing this you will see that there are usually a lot of dependencies in the scenarios. And some attributes do not really matter (they are a given, so no choice!).
- describe the impact (positive, negative) of each scenario, in terms of costs, but also in terms of impact on users, etc.
- and then make your choice ...
And finally: Do not make a Big Choice if you cannot follow up the choice with a clear impact on investment.
Labels: architecture
Big Choices & Investment Proposals
So architecture can be descriptive (pretty pictures) or prescriptive (rules) and although I think that the pictures are important, the architecture will only start to work when the rules are being applied.
So if architecture is prescriptive (see previous post), then the foundation of architecture is making choices, Big Choices. Of course making the choice is not good enough - it needs to be based on a good rationale. So when the architecture prescribes to use e.g. Linux as the platform for the Oracle database, then the choice needs to be based on a number of good reasons (e.g. the support for grid computing, cost, etc). The good reasons usually can be derived from the principles - as described in an earlier
post.
Once a choice is made it should also be supported by sufficient investment. You cannot make an architectural choice for say Linux, without providing the means to support that platform. With other words - architecture cannot live in isolation. It cannot describe a desired future state, without influence on the means to achieve it. So bottom line: Don't start doing architecture if you do not think you can influence the investments direction with your Big Choices!
Labels: architecture, principles
