Thursday, December 9, 2010

More thoughts on EA


I agree

  • "EA for the sake of doing EA ...flounders aimlessly in search of respect....IT needs to start thinking more like the business and less like engineers"
  • "EA practitioners should be focused far more on enabling a deeper understanding of the purpose and capabilities of the enterprises they work in – to facilitate greater clarity of reasoning about strategic options and appropriate action – rather than taking on an often obstructive and disconnected IT strategy and governance role" ...
  • "... capability map as a portfolio of business components ...the next level of details need only to be captured as new programs require them."
  • " ...traditional views of EA (People, Process and Technology) are too simplistic to support the diversity of business models. [Need] ...business architecture assets targeted at different levels of abstraction and produced in a contextually appropriate way to facilitate a far greater federation in decision making and implementation.]
  • "... you can no longer afford to ignore the ecosystem in which the enterprise operates"

I disagree that:
  • it is "... impossible to keep a centralized view of how the enterprise works -at a cost that would justify the value of such a view. ...". However maintaining a view requires changes to methods and tooling so that view accretes as a natural by-product of other activities and does not require capture for its own sake (Cf. cadastral data capture).


Monday, November 29, 2010

Interfaces

I am often asked what the right way to record interfaces is. The answer is really that it depends what you want to know about the interfaces and that in practice you will probably want to record information at a number of levels

Let us examine another communications paradigm we are all familiar with – Bill communicating with Bob.

Should one record that:

1. Bill Communicates with Bob (remember communication may be multimodal)

2. Bill makes sounds with his mouth that Bob hears through his ears (and similar for other modes with different input and output interfaces).

3. Bill makes sounds that are communicated via a medium (e.g. air), or converted into electrical signals and transmitted via an electrical cable, to a switching mechanism etc.


See diagrams of three example options below



There are a myriad of other strategies e.g. Bill communicates with clients (and Bob is a client); or Bob's brain interprets the sounds and hears the words and emotional content, etc. Then there are the issues associated with the semantic content of the message e.g. do we want to record that Bill is communicating about Products, Pricing or whatever

Well it really depends on what we are trying to understand – if we want to understand communications flows in a organistion, or if we are designing a phone etc. It make be useful for different purposes and audiences to record this at many levels and to be able to relate these different views together.

Unsurprisingly the same is true when one considers who to record communications between applications. The way you record them varies based on the purpose. They may be recorded in multiple ways and it is very handy to be able have a way of see how all the different levels are related. But searching in vain for a single way of recording interfaces that will serve all audiences and all purposes is unlikely to be productive.



Thursday, November 25, 2010

Traditional processes and EVP no good for EA

Even Microsoft is now saying "Traditional enterprise architecture processes do not work" (said by Gabriel Morgan, principal enterprise architect of Microsoft 10 days ago). He also said other things we have said for a long time e.g.
- "We have to prove IT’s value to deliver that market position"
- "We cannot develop a sustainable target architecture if we don’t know where we are"

So perhaps EAs will one day listen and stop doing what they have done i.e. using Excel, Visio and Powerpoint to try and do EA and look at what is actually required.

Dealing with complexity

I think this presentation indicates how useful visualisation are in dealing with complexity.

It mentions that it is important to set back and embrace complexity, and then look at issues in context.

It also demonstrates how dynamic visualisations can be powerful in analysis where one can selectively hide, decompose etc. the views. And to my mind why static crafted hardcopy reports will often struggle to allow us to examine new issues that arise, and what-if analysis i.e. it is the ability to interactively explore the data from many perspectives that is critical to the insights.

It is only by understanding how to deal with complexity effectively and good using solutions and tools to deal with it are we going to get any better at making strategic transformation or optimisations of the increasingly complex systems that are large enterprises.


Wednesday, October 13, 2010

EA's need to understand money and be prepared to change

I do not know what to make of some central Enterprise Architecture functions who do not seem to appreciate the need for transformation or have a grasp of economics. Transformation is about changing how we do things. Economics must ultimately drive all EA activities i.e. a strive for business value, and understanding of cost alternatives etc. Or more accurately they have academic understanding they advocate for others but are relucant to apply to themselves.
These functions will happily create a central repository of information about the enterprise that is critical to executive decision-making and optimal excecution of initatives. Yet they persist seeking to create artefacts from this repository e.g. documents, PDFs rather than just let others in the enterprise directly access the information and keep it up to date themselves.
When asked why they don't provide access they cite cost of providing access and that people are used to getting documents and don't want to change.
I recently examined the cost issue. I calculated that the cost of providing direct access to accurate online information that can be drilled down in to, and dynamically visualised. I then equated that cost to the cost of the people's time. It showed the cost for access or visibility is less than the cost of 1 minute of the person's time. The cost to provide people the ability to interactively update the data (and then do what if) would cost perhaps 2-3 minutes of the person's time.
So clearly any rational analysis would suggest cost is not the issue, which leaves us just with the business change issue i.e. changing people's behaviour.
So frequently we have people earning 6 figure salaries who either don't seem able to work out that for the cost of 1-2% of their cost they could do a substantially better job; or don't really care about how good a job they do.



Monday, August 2, 2010

Some recent thoughts on EA

Comments on 5 useful recent thoughts from others on EA (and some others)

My conclusion.

I think we can see a broad consensus on the need for more focus on business issues; collaboration and communication (speaking in language business understand not technical terms/languages) etc. Most importantly the need for vision and leadership.

1. The Quantum of Integration: http://advice.cio.com/brian_hopkins/10949/the_quantum_of_integration.
.. The act of thinking about something from different perspective actually influences the architecture. The focus on the business issues (e.g. capabilities) is often what one finds lacking.

2. Trends in Enterprise Architecture:http://advice.cio.com/brian_hopkins/11157/trends_in_enteprise_architecture
I agree there will be
- ... more business focused, delivering measurable value through strategy, governance and focus on critical interface between key enterprise components.
- ... more emphasis on strategy, process and governance and less on frameworks
- ... important skills for EAs are shifting toward the Business and Information layers in the Architecture domain stack
- ... EA activities that provide immediate value to the business are better first steps towards maturity. Focus on providing easily consumed, strategic deliverables that executives can use to make decisions
- ... Less "boil the ocean" analytic exercises with dubious short term value will be tolerated.
- ... define repeatable processes for producing EA deliverables then measure progress against these with a set of metrics.

3. Collaboration in EA is the key to Success -http://beyondea.com/2010/04/collaboration-in-ea-is-the-key-to-success/ is an excellent item by Denis Suto

4. The state of enterprise architecture: Vast promise or lost opportunity?
http://www.it-analysis.com/business/change/content.php?cid=12213
Fehskens:
... the discipline of EA and compare it to mature professions ... we’re back 200–300 years ago.
... you have to be able to do it [make the argument] in the language of the audience that you're speaking to. This is probably one of the biggest problems that architects coming from a technical background have.
Ross:
... reluctance to think that the way we get more value from IT is basically by taming it, by establishing a vision and building to standards and understanding how that relates back to new ways of doing business, and actually developing standards around business processes and around data.
... The architect’s role is to make sure that there is a vision....
... "... we need to begin generating value from more disciplined processes."
Hornford:
... underpinning all of that is what is the business trying to achieve? What is their vision and what is their goal?
... have to be very clear on what is the end state, what is the goal, what is the business transformation, and how will the digital assets of the corporation—the IT asset—actually enable where they’re going...
... fundamental with leadership in EA is that architects don’t own things. They are not responsible for the business processes. .. They are responsible for leading a group of people to that transformation...
... If you don't have good leadership skills, the rest of the fundamentally doesn’t matter
... If you do not lead and do not take the risk to lead, the transformation won’t occur. One of the barriers for the profession today is that many architects are not prepared to take the risk of leadership.

5. Chris Curran's EA blog - his comments in blue, my views bold:

- An exhaustive enterprise level blueprint is virtually impossible to build
Wrong and based on the wrong premise, it is like saying and exhaustive view of our finance (accounting) or customers (CRM) is impossible to build. Obviously it isn't if it built using an enterprise by the enterprise.
- The best strategy blends a direction-setting enterprise blueprint and business unit and domain blueprints
Perhaps, not if the strategy is to abandon or outsource the unit/domain.
- Centralized accountability for the EA function is a predictor of success - A centralized team of architects is critical in driving EA standards and approaches
Partly correct, a centralised team of people anyway (architects may focus on the wrong things) and a these in fact to be engage a distributed set of SMEs, the project teams how consume.
- Architects must be assigned to projects as core team members - perhaps. Are town planners assigned to building design projects.
Maybe. Governance shouldn't be done by pursuasion or covertly (the town laws, or electrical wiring code doesn't pursuade adoption - it is mandated)
- EA should be measured in 2 ways: business capabilities delivered and costs of core services
Wrong - I would say their are other ways e.g. risk reduction
- Measure EA as an asset
Perhaps, but it is hard do measure the value of a better strategy? It is easy to see Steve's Job's strategy was right now. If it was obvious before hand why didn't others do it.
- Architecture leadership requires strong management, business operations and technology skills, most likely in 3 different types of people; don’t expect your chief architect to run the EA function
Yes.
- Methods and governance must be integrated into existing work processes rather than an overlay
They be both (see town planning - methods are integrated into delivery and their is an overlay checking compliance).
Enterprise Architecture is not always the best name for communicating; maybe Strategy & Planning or Enterprise Transformation is better
Yes.
- The best large companies have “business architecture” teams reporting to the business (or dual reporting to business and IT)
Probably - I have not seen the facts
- Leading companies have reference architectures in place for 90% of the technical domains - Maybe - I have not seen the facts
- Senior enterprise architects must have the right cultural skills and awareness to integrate well with upstream business partners and downstream technical users
Yes.
- High performance groups maintain consistent, formalized EA involvement in the SDLC to translate blueprints into sufficiently detailed starting architectures for each project as well as accurate cost and resource estimates
Yes.
- Mature organizations target 40% EA resource time for strategic planning and 60% on SDLC tasks, and typically err on spending more time on SDLC tasks
Maybe.
- Strong credibility and trust amongst Business and IT partners is a predictor of EA success. Credibility has typically been gained via joint strategic planning efforts, one project at a time - Yes.

Some others:
http://www.zdnet.com/blog/service-oriented/four-ways-to-boost-enterprise-architectures-business-value/5240
http://www.infoq.com/news/2010/07/ArchitectureStrategies

Capability maps for Business Alignment

Don't Just Build Business-IT Alignment, Map It: http://www.businessweek.com/idg/2010-07-26/don-t-just-build-business-it-alignment-map-it.html. This is a really useful item. My precise below.

CIOs need to be able describe IT functions in business terms. Alignment occurs when people have a common understanding of what's important to the business, how this relates to the business model and the supporting technology, and where to prioritize investments for measurable improvements.

Business capability maps provide a framework to capture, assess, and communicate these needs. These maps put technology strategies in the context of the business process, functions, and capabilities they affect, and help enterprise architects design application and information architecture.

There are no industry standard models or frameworks to guide architects in their development. Forrester developed a six-step process that provides the foundation to successfully build and apply capability maps.

Step 1: Identify the Business-IT Alignment Issues - interview stakeholders to get differnt perspectives. Start with IT and use the results of those interviews to refine the process before moving to the business. Analyze the interview data to find common problem areas. Validate the identified problems with stakeholders to ensure that the accurately reflect their concerns.

Step 2: Define Your Approach - Create a current-state view that includes the issues and a future-state view. Use the current and future-state views to map alignment Issues to solution options. Focus on tractable issues. Define the roles and resources needed to make the initiative successful.

Step 3: Develop the Business Case - Develop a resources project plan (showing ramp up). Identify risks and mitigation approaches. Determine tools and technologies. Develop a cost estimate. Sell the business case.

Step 4: Build the Capability Map - Determine your organising principle e.g. value streams, business functions, services to clients and define the capability framework. Validate the structure by focusing a single element and identify capabilities for that element and add details (narrative description, people, process, technology, information, business goals, metrics, and gaps). Repeat across all of the organizing elements.

Step 5: Apply the Capability Map to Identified Problems - Create a capability map view to that focus on the decisions to be made. For exmaple for investment decisions analyse performance of core capabilities that provide significant market differentiation and competitive advantage to see where investment need to be made.

Step 6: Assess Progress and Refine the Approach - Examine the work to date. Re-examine interim deliverables. Identify unforeseen issues that affected progress, and plan forward and adjust the framework based on knowledge gained.

Thursday, June 3, 2010

ESTO success sealed with a KISSS?

Once again I feel compelled to suggest that we learn about how to implement Enterprise Strategic Transformation and Optimisations (Enterprise Strategy and Architecture, Strategic IT planning etc.) from another domain focused on the enterprise use of knowledge and collaboration based on that knowledge i.e. CRM.

See: CRM Success Sealed with a KISSS - http://www.computerworld.com/s/article/print/9177484/CRM_Success_Sealed_with_a_KISSS?taxonomyName=Applications&taxonomyId=18

Most people with experience in trying to change patterns of behavior know that incremental change is easier for people to accommodate. Most people with experience in trying to implement systems know that big-bang approaches are high risk. Implementing new systems for knowledge management and collaboration involves both i.e. changing behaviour and implementing systems.

ESTO solution projects also "need to be much more flexible and adaptive than general IT applications. All too often, the users don't really know what they need, and the smart ones will admit it. Even if they did know, the business rules and your company's competitive environment will change before an 18-month "big bang" project ever gets deployed. ESTO projects are not only less expensive when delivered incrementally, they are a better fit with the business needs. So it's important to get your project staff -- and the ESTO system's executive champions -- comfortable with Agile.

Personally I have issues with methods that are focused on, or derive from, SW development being applied at different levels. And I think that SW developers per se are too keen to see each problem as one that requires development i.e. to get 100% fit might require development; but using an OOTB solution that reflects best practice might get you 80% of the way there - in 10% of the time.

I think the comments on vendor roadmaps interesting - and what we really need in ESTO is an aspirational roadmap with features defined near release drops.

See other ideas from comparisions with CRM:
- http://enterprisesto.blogspot.com/2009/08/what-price-sitp-data-quality.html
- http://enterprisesto.blogspot.com/2009/07/8-dirty-little-secrets-of-enterprise.html

Wednesday, May 26, 2010

Virtuous circles of strategy, architecture and delivery

If we don't support a virtuous circle of use - we won't achieve much (and certainly not cost effectively).

The majority of people who need to consume an Enterprise Architecture and Strategies are business teams (owners, analysts etc.) and solution architects, designers etc. i.e. down-stream project teams wanting to do something (buy, build, change etc.). NOT other EAs and Strategists. You can see the same thing with a town plan i.e. the majority of people who consume the town plan are property owners, architects etc. wishing to do things.

Governance functions also have a need (e.g. project office, contract/vendor management, business case analysts).

Until EA can effectively understand its place in the lifecycle of think, plan, excute, operate - it will struggle.

Enterprises wish to make changes (transform, optimize) and EA is intended to guide these changes (it is not an end in itself). The changes will usually be implemented in initiatives, programmes, and projects. Those involving IT will usually have requirements, solution architectures, etc. These projects are where the rubber hits the road.

So EA needs to be consumed by down-stream projects - which will indicate their use of existing assets (applications, services, interfaces, hardware etc.), standards (products, technologies, patterns), capabilities (skills, resources) - and indicate where they will produce new assets or require new/different standards to be adopted or capabilities established etc.

Most of what one sees in a tradional EA once came from some project that drove the need for it. This is true on the business and technology side - but is usually more obvious with technology.

An EA needs to be produced and consumed both bottom up and top down.

Thursday, May 6, 2010

EVP - Powerpoint fails to deal with complexity well - who would have thought

I have heartened to see this "U.S. Army discovers PowerPoint makes you stupid" (http://blogs.computerworld.com/16006/powerpoint_makes_you_stupid?source=CTWNLE_nlt_entsoft_2010-05-03).

For many years I have been presented with powerpoints that claim to communicate complex things e.g. strategies, roadmaps, architectures, transition plans etc.

I have been perplexed when on examination the PPTs turned out not to contain the information necessary to describe the complex situation being dealt with. I am then asked how do we model these - or why can't you produce a model, visualisation or report that communicates like these do. The reason is that the powerpoints are often specious - being favoured by executives, sales people and other trying the illusion that analysis has been done and sound conclusion reached based on facts - when in the facts, analysis and conclusions are at best usually disconnected. If one points out the limitation of the powerpoint source documents - one hear "Oh so you don't know how to represent this". Well the answer is that if the data is rubbish expressing in a semantically precise way will just highlight that it is rubbish. This doesn't to fly well with the executives.

I like these quotes:

"Have you fallen in love with your bulletized slides, nifty transitions, and pretty charts in PowerPoint? If so, you're likely getting more stupid ..."
"... We Have Met the Enemy and He Is PowerPoint... When we understand that slide, we'll have won the war."
"It's dangerous because it can create the illusion of understanding and the illusion of control. Some problems in the world are not bullet-izable."
"... it leads to bad decision-making, with serious consequences ..."
"... that tremendous amounts of time are spent in the military on putting together presentations, and that this takes away from true productivity."
"... [PPT] does come in handy when the goal is not imparting information, as in briefings for reporters." [or executives]
"hypnotizing chickens."

Wednesday, March 17, 2010

Artifacts vs Business Results

I am often involved in looking at how people can improve their IT processes e.g. in areas of strategy, architect, governance and service delivery.

Firstly let me say I am fairly familiar with principles underlying OO analysis and design techniques having started using them in the mid 1990s (before UML, and before Java). Naturally when UML emerged as a defacto standard we moved to it; and to RUP which followed soon after. Having overseen many large projects using OO analysis and design techniques I think I have some understanding of what needs to achieved.

Now an apparent digression - Almost 30 years ago when I specialised in CAD and Mapping systems I used to have to explain to Architects, some of whom had been my tutors, the benefits of CAD. They pulled out beautiful water colours and asked if the CAD system could produce them. They had mastered the skills of producing these works of art over lifetime and were justifiably proud of them. At the time the answer was "no". Of course the CAD system could convey the essential information but the way in which conveyed it was different. And of course the cost to produce any ad-hoc view (plans, elevations, details etc.) or deal with changes using the CAD system was far lower. Also the CAD system could be interactively inspected, do counts etc. What these artisans failed to grasp was that what the client wanted as business not a water colour i.e. the business result was the building, the water colour artifacts were incidental.

I now encounter the same issue with people looking at various artifacts related to manual methods of solution design - the classic being the large SAD (seldom if ever read by anyone but the author) or in strategic area some large attractive diagrams manually created with many pretty colours. People seem to think the artifacts (e.g. SAD, Roadmaps etc.) are important per se. In my view they fail to focus on the business results to be achieved e.g. a transformation to be made, or a project delivered and really examine what information is required by whom, when, where and why.

I had a lot of sympathy for those being asked to move from water colours. While they required an experienced practioner and some time produce a result was aesthetically pleasing and communicated very well to many audiences i.e. technical and non-technical (if limited to a specific point of view e.g. plan, perspective, detail, elevation etc.) I have a lot less sympathy with IT people today wasting energy trying to replicate some arcane symbols (e.g. associated with modelling logic, processes, objects or data). These also require experienced practioner and some time produce. The result are neither pleasing nor particularly communicative to average person.

Wednesday, February 10, 2010

Business architecture as part of Enterprise Architecture

I saw this and thought some of the quotes interesting
http://jccavalcanti.wordpress.com/2010/02/10/defining-business-architecture/

"...BA is an intrinsic component of EA, but what most people really perform in most organizations that I see is IT architecture."

"... enterprise business architecture is a set of artifacts and methods that helps business leaders make decisions about direction and communicate the changes that are required in order to achieve that vision."

"... It's our excuse sometimes that it's too complex to change quickly."

"... We really need to focus the conversation on capabilities..."

"... BA is a means by which we can engage as IT professionals with the business leadership, the business decision-makers ...

"... By having that meaningful dialogue on an ongoing basis, not just as a result of the big implementation ..."

"... understanding your audience is a big part of doing this.

"... That's why there's no, "This is the artifact to create." ..."

"... there's a missing linkage between that vision, that strategy, that direction, and the actual activities that are going on ...

"... jump from high-level strategy down to tactical daily decision-making and activities is too broad of a gap. .."

To me this supports my view that:

1. The BA is intrinsic to EA (though EA function focus on technology).
2. EA needs to support decision making and communicate what needs to be done to achieve a vision (goals, strategies, plans and down to requirements)
3. The excuse made that it is too complex to change quickly indicates a failure of EA.
4. BA needs to focus on capabilities and allow us to engage with the business leaderships (so we need to use the right language)
5. Waiting till a big project to justify the dialogue is like waiting until you are attacked to learn how to defend yourself i.e. it is just dumb
6. Understanding the audience is critical and what and how you communicate varies based on the audience.
7. There is a missing linkage between that vision and plans that live in PPT decks on the shelves and what happends on a day to day basis.

Saturday, February 6, 2010

Communicating with people in languages they understand

For many years I have run foul of SW developers how have migrated into Architectural roles - but want to continue to use the techniques and languages suited to the role of OO SW development.

Open Group advocates are often some of worst as many are committed to UML - a language manifestly unsuited to communicating with most business people most of the time.

I recently read this: http://blogs.zdnet.com/Gardner/?p=3450. And saw these comments:

"To achieve business-IT alignment, architects need some way of understanding what the business is really about. ...

We need to talk to business people to understand what the business architecture is, but the business people don’t want to talk tech-speak. ...

We need to be able to talk to them in their language, but addressing an architectural end. "

And I wonder when the penny will drop that this language isn't UML.

Friday, January 22, 2010

What impedes the development of Information Architecture

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

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]