Wednesday, December 19, 2007

Process Architecture

One of the things that usually surprise when I have to deal with McKinsey types is that their focus on business is very process oriented. Activities flow from step to step, from unit to unit, but where is the data?? By not addressing the data dimension in organisations I see that they usually leave stop-gap measures to business issues, since only part of the solution is addressed.

This is why Enterprise Architecture (EA) methodologies are relevant for data management as well - EA addresses process, applications, data and infrastructure and treat them all as equal ..., but because most consultants have a enormous focus on functionality or technology it is important to give data an even higher profile during an EA exercise. So Data Managers - use your architects to get data on the map!

Labels: ,

Monday, December 17, 2007

Keep it simple

I noticed that I wandered off quite a bit over the last few months - from the original trail about data management, towards more architecture oriented notes. Probably because I started noticing that architecture can actually add a lot of value to the cause of information management. An architect can do a lot of things - add principles, look at reusable services, create an overview - look at more than just the requirement of that moment by that small group - etc. But I think the key role of the architect is to make things simple.

The synthesis of the analysis over various systems should be something that is simple to sell, because it is simple to understand. I have now seen people trying to sell a concept like an Enterprise Service Bus (ESB) - and since they could not explain what it was they failed in their message. If their message would have been about integration and agility, then it would have made a bit more sense. If the message would also have shown a stepwise approach towards a full blown solution, then maybe people would have bought it ...

So as an architect - the key message is the good old KISS principle - Keep it simple, stupid!

Labels: ,

Monday, December 10, 2007

Architecture maturity

Recently I came across a book from consultants from Sogeti. The book describes how to set up an architecture practice.

The most valuable bit in the book is a matrix about architecture maturity. The nice thing about this matrix is that it helps positioning where your organisation is in terms of maturity and what the next things are you need to do to get higher up the scale. It also gives the message that architecture development needs to be a balanced program with activities in many areas - so investing in e.g. just skills, or just organisation is not enough.

An eye opener for instance is that tools for describing meta data only work in mature architectural set-ups, so therefore investing in it at the start is basically wasted money. So bottom line - this is recommended reading if you start thinking about setting up an architecture organisation or program.

Labels:

Friday, December 07, 2007

More on principles ...

Earlier I wrote about data management principles and data architecture principles, and I stayed with these principles in the comfortable realm of IM&T - i.e. the area where we have more or less control over what we do. The thing I learned recently is that there are also 'higher' level principles that may be of value to drive the 'lower' level principles on data & architecture that I mentioned earlier.

Let me call these higher level principles the Business Principles. These are things based on where our business context drives us and what we want as a company. They are basically the things that link the data architecture to the business.

Usually we get a bit vague when we talk business drivers and objectives. But when doing architecture, they are vital for defining direction. For example - say your business is about differentiating technically. In that case your IT architecture should support this and a complete focus on e.g. operational efficiency and cost is probably the wrong focus. Or say your business is about reacting fast to market changes - in that case you cannot afford projects running for 4 years to deliver large solutions, but you should in fast in a platform that allows for agility and change.

Defining these business principles is a key step towards defining a good architecture, and therefore a necessary step, which is quite often forgotten (especially by IT managers with a focus on costs)

Labels: ,