Immature methodologies
Togaf, Dynamic Architecture, etc. lots of methods exist to define your ' Enterprise Architecture'. The existance of this plethora of methods is a sign of the immaturity of our discipline. We spend lots of efforts in coming up with even more ideas on how to do things right, but I guess we are missing a point here, since the more methods we invent, the more confusion we create. And the more we realise that we actually do not know ...
The other immaturity is that whatever we invent seems to be too complex for implementation in large organisations. With my current experience I would almost recommend to skip the details of any method and focus on the big picture - and here we see a lot of commonality between the methods.
The other thing is that most methods seem to be focused on a relatively confined scope (a single business proces) and in these cases it is quite often overkill to use it (just keep it simple and use the tried and tested methods for system design and don't sex it up to call this 'architecture') .
Labels: architecture
Re-coupling
Architecture is a lot about
de-coupling - this is trying to ringfence functionality in order to manage complexity, allow specialisation and allow improvements through 'service management'. This trend has happened for many years in the industry, but now a new trend is emerging:
re-coupling. Some examples:
- travellers now book their own flights (and not via the travel agent - the old point of de-coupling)
- bank customers do their own data entry (and not the back office in the bank)
- specialist processing activities can be carried out by non-specialists
This trend is interesting, since in information management we see that the de-coupling of e.g. data related activities has quite often not happened and now we see more information related activities moving back to the user again.
Is this a good trend? I think it is not in the case of running a business. If we can move certain information related activities to information handling professionals (e.g. data receipt, basic QC, cataloguing, help with retrieval services, etc.) then we will make the more expensive engineers more effective. So bottom line - before we start re-coupling (which seems to be more a consumer trend), let's focus on de-coupling of services related to information management.
Labels: architecture
Fighting perceptions, through certification?
Recently I read an interesting letter in a dutch newspaper - which told me a lot about perceptions people have about IT. The industry was accused of being 'technology pushers', with lots of promises, no realism and through that responsible for the many well-published failures. The letter ended with the idea to claim billions of dollars from the IT industry for frauds like the Millenium bug.
The letter was a reaction on an article about large government IT projects - why they fail. The article itself was pretty clear; using IT to push change, with ill defined scopes, ... etc were all to blame - and I fully agree with this. And as you may understand from my blog - I am convinced that more 'architecture' and more focus on the softer side in project in these type of project may help (so technology becomes less of an issue as well).
But I think there is more. Why is it that still many people see IT as a big scapegoat for everything that goes wrong? Why do people underestimate the complexity of large change projects (and think it is an IT problem)? Maybe it is true (in a way) that some of our professionals do push technology before looking for real solutions - and that's why I have advocated to but more 'I' in IT. But how do we achieve this?
Maybe as an industry we should have a 'code of practice' that prevents us from doing projects that are un-achievable? Maybe we should only do projects when there is sufficient resourcing & the right approach! I guess that's all wishfull thinking. As an industry we have already tried to set up all sorts of certification scheme's - but the bad news is that certification does not always help! CMMi level 5 means first and foremost a lot of bureaucracy - and not necessarily that you get the right solution for a clever designer for the right price. PMI certification does not mean that the project manager is a really good communicator (which is 50% of project management!). Now I have also seen architecture certificates popping up and even stuff related to data and document management ...
As I wrote earlier - IM is an Art, in some ways, and in many ways it is closer to social science than it is to technical & engineering. In the same way Architecture is an art as well - but an art with a purpose. Just like Norman Foster creates beautiful functional buildings - we should recognise the great IM & IT architects in terms of their artistics skills beyond the certificates. And we should make clear that these enablers for real change cost more than the bog standard VB programmer (so when we source project that we do not always look at price).
I only don't know how we can define this quality label, if certification is not the answer. Can we learn from the academic world? (citation index, peer reviews, ...) I don't know - but it is a thought.
Labels: certification
Process Architecture [2]
Earlier I wrote about Process Architecture and how we usually have a bias towards functionality. Re-reading this I must admit that I stepped over the fact that process analysis is still very useful. Understanding the main functions in the organisation and understanding if they can be run as 'services' is a useful exercise. Services are organisational functions which can be ringfenced and managed through well defined interfaces. The interfaces usually have the nature of a Service Level Agreement. Defining services also allows de-coupling and usually it is data which goes over the interface - and there we see a purpose for data management again.
Labels: architecture, Process
qaotiq.com
I have been writing over the last few months a few times about the power of wiki's and the importance of reference data and now I would like to combine & test these ideas. Therefore I have created a new site -
qaotiq.com. A soft go live of the site was yesterday (there are still some bugs ...).
The idea is that it is possible to create your own lists of reference data and share these with others. The items in the lists can link to e.g. wikipedia or sites like Flickr or Google maps.
Eventually over time I expect a data model to emerge of all sorts of linked lists ... Let's see if it works - you're invited to join!
Labels: master reference data, Web2.0, wiki
Architecture and Information Services
I strongly believe that most organisations today are mostly dealing in information and therefore - building a layer of 'information services' is something that should be considered when trying to build a sustainable and agile architecture.
What is the story of information services? Information services are a way of decoupling data from functionality. In the past this was already done by creating databases - but usually the databases were application specific. In the mind of most programmers there cannot be data without an application.
When applications started to grow and started overlapping, then the concept of shared data emerged - this happened at the end of the 'eighties' and suddenly people started to think about designing major data models. One of the most glorious attempts was the 'Epicentre' datamodel - designed by the Petrotechnical Open Software Corporation, an object relational database for the oil industry with more than 2000 tables. It was very clever, very flexible and very hard to implement. And therefore it was never a success.
Obviously these heroic attempts were doomed and with the growth of off-the-shelf applications we saw the rise of ETL tools (to get a grip on all the interfaces) And quickly after the rise of ETL, with the rise of the Internet, we saw a complete market growing of middleware solutions.
As information managers found out - it is also possible to create spagghetti with middleware solutions as well and now eight years after the millenium we are back at where we started - we are crying out to get more control on the information.
And this is where the information services story comes back again. If you put information at the center and 'wrap this up' as a service, using a canonical data model (a bit like the Epicentre data model, but then more pragmatic ...), then it is possible to reduce the complexity of your architecture. The data can be in various places (so don't think about large corporate data stores) and the middleware just 'knows' where to get it. The applications just 'shop' for data from the middle layer and the 'bus' is doing the work. Well this is where the complexity is - building the 'bus' is the hard work - since it requires
- rationalisation of data sources (agree where is the master)
- common definitions (or at least agree how to transform)
- routing (agree how the data flows)
And this is where we in IT are not good at - it is great to define a lot of new functionality, but to crawl through the sewers of data management is very hard. But if you want to succeed in getting control on your information centric entreprise, then think 'information services'!
Labels: architecture, middleware, SOA
