Prompted by: Forrester: Information Architecture Matters - Survey of enterprise architects finds information architecture is immature and undervalued.
http://www.information-management.com/news/forrester-information-architecture-matters-10016994-1.html
I think the obstacles of IA is the preponderance of people involed who see data in relational database terms (or in terms of other implementation methods and standards) rather than in terms of the business questions, knowledge and information.
One sees similiar, but perhaps lessor, issues with business architecture where the people involved want to see things in terms of Use cases and techncial process execution (e.g. BPEL) - rather than focusing business capabilities, functions and process.
The higher levels are intrinsically less transient and not really related to technology per se.
In both cases the boil-the-ocean problem arises from starting at the bottom of the pyramid rather than the top. The absence of a sound top level means the framework for progressively elaborating lower levels as a by-product of execution projects doesn't exist (or isn't used).
Forrester proposes a process or methodology solution - but the solution in changing the people i.e. changing the behavior of people in the roles; or changing the people who inhabit the roles.
It seems to me nothing much has changed since I wrote this
http://ea-in-anz.blogspot.com/2007/09/enterprise-data-management.html
In this I identified some things:
- Information management strategies are going to have to improve.
- Most organisations can't even provide a high level map of their information - it is buried in silos (maintained by a technical clergy with arcane interests)
- Most organizations don't have a handle on the relationship between business information and the underlying ICT systems that implement the data
- Most organisations can't explain what information is associated with what: process, service, rule etc.
- Most CIOs can't have candid conversations with their business counterparts about what the real issues are associated with managing todays data or dealing with more data.
I suggsted some things that should be done
- a knowledge base which could act as hub
- the boundaries between the hub and the various spokes (e.g. ER modellers, XML modellers etc.)
- inventory data and usage
- benchmark against industry Reference Models
- defining architectural principles and goverance approaches
- analyzing business information context
- develop optimisation programmes
Friday, January 22, 2010
Thursday, January 14, 2010
Inspired by "13 Enterprise Modeling Anti-Patterns & How to Avoid Them"
I saw this today: 13 Enterprise Modeling Anti-Patterns & How to Avoid Them [
http://www.linkedin.com/e/avn/103346240/1814869/EML_anet_nws_title-cDhOon0JumNFomgJt7dBpSBA/]
I thought it presented some useful points albeit often otiose. It mixes two issues i.e. how to do enterprise modelling (SITP) and what the results of good enterprise modelling (SITP) should be e.g. avoiding immature or unstable technologies (except in rare circumstance) should be a result or conclusion from for SITP - but it doesn't really tell us about SITP per se. I am interested in SITP and focus below on aspects that relate SITP method.
I think it can really be boiled down to 3 things
1. Audience, Purpose and Use are critical - The one thing it repeats many times in many ways is that you need to model with an audience, purpose and use in mind. This means models won't be too detailed i.e. if they are fit to purpose. It also implies that you will look at how to engage with the various stakeholder (rather than doing what suits developers who in my view have often hi-jacked the process). Lastly this means that you must have some idea of a path to implementation as few stakeholders will proclaim to know things for no purpose other than to know them i.e. stakeholders will clearly say we want to know so we can decide and act.
2. Ongoing knowledge accretion - It also points out that you need to roll things out (when they are not perfect) and let them evolve and mature.
3. Know what you know - Understand what you are capturing e.g. an essential aspect, just how it is today (but not how we would like it to be), how we would like it to be (but not how it is)
The things it say to avoid (with by comments in [ ]) are:
30,000 feet and climbing
- avoid models that are too high level [well this is tautology];
- ensure models have a practical use [but this is absolutely key]
Detailed enterprise model
- model just enough detail [this really comes back to understand the use i.e. the point above].
-- Model with a purpose [yes].
-- People rarely read the details [Well this really is a problem with the concept of models and it is most people are not interested in most detail (detail about other peoples domains]. This is not to say that the detail should not be understood or recorded. It is to say that the detail should only be presented to the people to whom it is of interest and when they want to see it]
-- Know the audience for the models [absolutely - or more accurately understand the audience for views of the data that answer question they care about]
Ivory tower architecture
- Create realistic models [?? what other kind of models are of use??] rather than perfect world scenarios [?? well surely one need to know how one would like things - this seems to conflict with a point below]
-- Get Development teams involved early [?? why on earth would you set out with the aim of doing development, surely development is necessary evil not something to be encouraged by premature engagement of people who like doing it]
Modelling for modelling sake [absolutely]
Real world disconnect - ensure models reflect the actual stakeholder requirments [absolutely]. So don't use arcane developer oriented modelling approaches e.g. UML, ERD etc.
Striving for perfection [there is nothing wrong with striving for improvement].
- Roll stuff out even if it is not perfect [This is the key aspect. The information and process needs to evolve progressively with the involvement of the whole community]
Getting stuck in the weeds [Well I would say - avoid capture transient implementation specific details unless they are critical for some reason and capture the essence of the issues]
"Technology above all" [yes] Make technology a business enabler not a business driver [well the fact is that sometimes the market/environment means that technology is or should be a a driver]
"Tomorrow suffers from today" [record how you would like things to be - which is why it is important to understand the essence of things vs. just their current implementation]
"Underground Future" ensure models create a clear path [yes - with out plans, initiatives and transitions a vision is not that useful]
"Yesterday's Enterprise model" - Once finished don't let your models get out of date [well this is oxymoronic. One never finishes, the models are an ongoing active record]
http://www.linkedin.com/e/avn/103346240/1814869/EML_anet_nws_title-cDhOon0JumNFomgJt7dBpSBA/]
I thought it presented some useful points albeit often otiose. It mixes two issues i.e. how to do enterprise modelling (SITP) and what the results of good enterprise modelling (SITP) should be e.g. avoiding immature or unstable technologies (except in rare circumstance) should be a result or conclusion from for SITP - but it doesn't really tell us about SITP per se. I am interested in SITP and focus below on aspects that relate SITP method.
I think it can really be boiled down to 3 things
1. Audience, Purpose and Use are critical - The one thing it repeats many times in many ways is that you need to model with an audience, purpose and use in mind. This means models won't be too detailed i.e. if they are fit to purpose. It also implies that you will look at how to engage with the various stakeholder (rather than doing what suits developers who in my view have often hi-jacked the process). Lastly this means that you must have some idea of a path to implementation as few stakeholders will proclaim to know things for no purpose other than to know them i.e. stakeholders will clearly say we want to know so we can decide and act.
2. Ongoing knowledge accretion - It also points out that you need to roll things out (when they are not perfect) and let them evolve and mature.
3. Know what you know - Understand what you are capturing e.g. an essential aspect, just how it is today (but not how we would like it to be), how we would like it to be (but not how it is)
The things it say to avoid (with by comments in [ ]) are:
30,000 feet and climbing
- avoid models that are too high level [well this is tautology];
- ensure models have a practical use [but this is absolutely key]
Detailed enterprise model
- model just enough detail [this really comes back to understand the use i.e. the point above].
-- Model with a purpose [yes].
-- People rarely read the details [Well this really is a problem with the concept of models and it is most people are not interested in most detail (detail about other peoples domains]. This is not to say that the detail should not be understood or recorded. It is to say that the detail should only be presented to the people to whom it is of interest and when they want to see it]
-- Know the audience for the models [absolutely - or more accurately understand the audience for views of the data that answer question they care about]
Ivory tower architecture
- Create realistic models [?? what other kind of models are of use??] rather than perfect world scenarios [?? well surely one need to know how one would like things - this seems to conflict with a point below]
-- Get Development teams involved early [?? why on earth would you set out with the aim of doing development, surely development is necessary evil not something to be encouraged by premature engagement of people who like doing it]
Modelling for modelling sake [absolutely]
Real world disconnect - ensure models reflect the actual stakeholder requirments [absolutely]. So don't use arcane developer oriented modelling approaches e.g. UML, ERD etc.
Striving for perfection [there is nothing wrong with striving for improvement].
- Roll stuff out even if it is not perfect [This is the key aspect. The information and process needs to evolve progressively with the involvement of the whole community]
Getting stuck in the weeds [Well I would say - avoid capture transient implementation specific details unless they are critical for some reason and capture the essence of the issues]
"Technology above all" [yes] Make technology a business enabler not a business driver [well the fact is that sometimes the market/environment means that technology is or should be a a driver]
"Tomorrow suffers from today" [record how you would like things to be - which is why it is important to understand the essence of things vs. just their current implementation]
"Underground Future" ensure models create a clear path [yes - with out plans, initiatives and transitions a vision is not that useful]
"Yesterday's Enterprise model" - Once finished don't let your models get out of date [well this is oxymoronic. One never finishes, the models are an ongoing active record]
Subscribe to:
Posts (Atom)
Posts
