Why don't most IT processes work well

(prompted by the common failure of processes for fairly obvious reasons)

The key problem with most IT processes is that they don't deal with the complexity very well. And IT is full of complexity (and is getting increasingly complex)l. The irony is that the IT technology used to implement most IT projects is perhaps 20 years or more old i.e. Word documents, Spreadsheets, Diagrams - but IT people unable to see that they more than most other aspects of the business are failing to execute effectively because they have not kept up with technology I will give some examples: Development methods (e.g. RUP) - putting aside the fact that the method is to a large extent based on the false premise that the functional business requirements can be captured in UML. A key impediment to its success is that its implementation involves a number of documents. These documents are necessary to contain knowledge about the project. They contain information that is high inter-related, and needs to be explicitly connected, and should be able to be analysed. This is manifestly not the case when RUP is usually applied. What is really required is a model/knowledge base that represents the project that can produce the RUP artefacts as reports (and there be more of these tailored to specific audiences and aspects of the project than are produced at present) - while at same time allowing the information to be analysed and connected (i.e. to what exist, to other projects, to quality measures/strategies etc.). This solution would also allow management dashboards to exist to allow management at atomic level. Of course RUP really came from the package SW development domain (which is also where most C++ programming was done). In this context i.e. where there is no specific business as such, no specific business users etc. and where the task is very much engineering (vs the capture and elaboration of requirements that emerge from mist - as is the case with most bespoke development) - UML is quite well suited. Business continuity - is another example of something that is usually implemented in a plethora of highly connected documents. These documents must contain knowledge about the business, technologies, plans, compliance issues etc. and these aspects should be explicitly connected, and able to be analysed. What is required is a model/knowledge base that represents the business situation (including plans for ensuring continuity of operations, and alternatives for executing) that can produce the documentary artefacts as reports and allows the information to be analysed and connected (i.e. to what exist, to other projects, to quality measures/strategies etc.) IT Investment management - [..WIP]

Troux 7 Released in the USA/Europe

Troux Delivers Industry’s First Enterprise Platform to Support IT Transformation

Troux, the leading provider of software solutions enabling successful business and IT transformations, announces the industry’s first enterprise transformation platform, Troux 7. The new, comprehensive solution, based on Troux's EA technology, addresses the primary objectives of CIOs and executive leaders i.e. to deliberately and systematically reduce costs, manage risks and drive investments.

Business transformations (e.g. global expansion, mergers, the creation of new product lines) can't be implemented without a set of IT activities to support the change. Often executives fail to understand and IT fails to communicate how such activity will impact the business, resulting in lengthy, complex projects and excessive costs.

A recent survey sponsored by Architecture and Governance Magazine revealed that 20% of respondents continue to struggle with demonstrating the value of IT projects to the executive team, leading to early termination of the project or even perceived failure.

"Alignment of IT to the business continues to be the most critical challenge for CIOs. We’re seeing ongoing frustration from the business as IT struggles to be more agile and proactive in their support of business requirements. A key barrier to this is lack of visibility to the range of IT assets, the relationship among the assets and their relationship to the business,” said David Hood, CEO of Troux. “With Troux 7, we’ve created the only system with the complete set of capabilities for EA teams and IT departments to successfully automate the understanding of the enterprise and how IT relates to the business. Troux 7 delivers a rich analytics platform to create transformation initiatives, allowing gap and impact analysis in multiple scenarios to identify IT support requirements for the business. Coupled with a baseline transformation plan for business alignment and the mechanism to monitor execution over time to ensure effective support, once again Troux’s innovation delivers an unrivaled solution to the market."

Troux is represented in Australia and New Zealand by RHE. Troux 7 is expected to be released in Australia and New Zealand next month.

To see the Troux press release click here. See also:

Troux adds advanced BI to platform (IT Week)
Troux makes enterprise architecture transformational (Computer Business Review)

Data Governance - Maturity Model

(synopsis of: 7 Stages for Effective Data Governance by Martha Dember)

There is a tendency in organizations to be complacent about data quality and integrity issues (which could compromise credibility of the organization's information).

Data Governance:

• is the development and integration of a set of rules/policies, guidelines, and standards - for managing data (not just a collection of ad-hoc data quality projects)
• provides the framework for IT and business to worktogether to establish confidence and credibility in the enterprise's information.
• is implemented by a data governance management team, of IT and business associates, unified by a common goal i.e. to ensure: data is what it is supposed to be (Data Quality); data is in the correct context (Data Integrity); data and its associated metadata are accessible (Data Usability)
• ensures the authority to manage data is properly delegated from the senior-most levels, and that parties are held accountable for executing governance policies as required by their respective mandates.
• has policies and procedures that balance effective information access with appropriate use of the information.
• is a programme (i.e. is not an application, that can be purchased, installed, and implemented with a specified end date) but a process that, over time, affects the culture and the way an organization conducts business.

Data Governance Maturity Model - requires a plan or framework (along with other things). In a data governance maturity model one can define seven stages of maturity .

1. Strategy and Framework
The Strategy identifies data issues, their causes and effects, and methods to solve the issues.
The Framework defines the roles/responsibilities of the data governance team and the relationships and dependencies between the data governance team and the data architecture.

2. Scenarios and Validation
Tests the data governance strategy and framework e.g. takes a data issue (reactively) and determines the cause/effect of the issue, and propose a solution to: refine the processes/framework; determine the communications (how best to implement the steps, and who should play roles).
Benefits: PoC using industry best practices that can be adapted to the organisation

Stage 3: Formalized Organization and Responsive Process Rollout
Formally define the roles (e.g. job descriptons)
Benefits: Accountability for establishing and maintaining data quality.

Stage 4: Proactive Process Rollout
Identify business events or activities that causes problems (data issues)
Benefits: Proactive processes improvements, better communication between business and IT (people can collaboratively manage data)

Stage 5: Expanded Business Involvement
Explicit buy-in from key stakeholders and executive management in the data governance program. Standards compliance monitoring is incorporated as a part of performance measurement; and data-specific technology, processes, and organizational components are aligned with the company's most important business objectives.
Benefits: Continuous improvement efforts are measured and monitored (metrics);Associated processes (e.g. SDLCs) can be improved; Data governance efficiency is improved (the knowledge base is used to reduce future project effort/duration)

Stage 6: Stewardship Culture
Governance across the Enterprise reconciles priorities, expedites conflict resolution, and builds cooperation in support of data quality as a common objective. Data quality education and awareness programs are an integral part of the on-going employee training programs.
Benefits: There is a common focus and delivery and everyone acts as a data steward (extending to business partners/channels)

Stage 7: Strategic Governance
Data governance and compliance becomes real-time, change-driven, on-demand process that continually assess risks, update policies, and manage resources across the enterprise. People, processes, and technology working together organically and autonomically that result in an effective data governance program.
Benefits: Utility of information can now drive flexibility and agility of the organization and result in a streamlined/efficient organization.

Thinking SOA (are the issues really that new?)

(prompted by thinking SOA)

I agree with the conclusions i.e.

- SOA is a core aspect of EA (and EAs that get this will get SOA more quickly)
- SOA does have new some challenges especially around lifecycles, service quality management and inter-party agreements - but think that in but in many cases the challenges have always been there - now it is just harder to bury your mistakes.

I disagree with some of the things implied i.e.
- Good EA has always been about interoperability (driven by business goals such as agility) - and never about layers of technology. So this is not something new with SOA.
- "Traditional enterprise architecture" is Technology Architecture (NOT EA). Many of frameworks, methods and tools - have been manifestly unsuited to real EA for a decade (hence the how few really success EA projects there are). So this is not something new with SOA either

See also: EA/SOA a shareholders issue?

EA and SOA shareholder issues?

(prompted by: Could Lack of SOA Drive Shareholder Lawsuits)

[WIP]
I can't really bring myself to agree with the conclusions in this item - that the absence of good EA's could drive lawsuits.

Key assertions from this:
1. Shareholders are looking at enterprise architecture efficiencies
2. Many major public companies don't have efficient enterprise architectures
3. Stockholers assume that IT/Architects, are doing their best to make the architecture optimal for the business. However, in many cases, that is not true.
4. Years of neglect, lack of talent and understanding, etc. have created dysfunctional EAs.
5. Bad EAs hindering corporations ability to make money and return value to shareholders
6. This could drive lawsuits where bad EAs may need to explained in depositions (during law suits).
7. SOA are not a fix for bad EAs - they will just make bad ones worse.
8. What is needed is a long term cogent SOA strategy and this is complex and hard, but worth it if you do it correctly.
9. Shareholders may ask for complete audit be done on the methods and practices in building an effective EA

Comments re the points above:
2, 3, 4, 5, 7, 8 - I think are fairly well known i.e. - Most major enterprise don't have efficient EAs and years of neglect, lack of talent/understanding are a cause. Few IT orgs are doing their best to fix this. Bad EAs do hinder ability to return value to shareholders and SOAs will make bad EAs worse (adding complexity) and what is needed is a long term cogent strategy. These strategies and architectures are complex and hard to do.

I think 1/6 - are unlikely. That shareholders will look at architectures and focus law suits on the deficiencies seems improbable to me for many reasons.

The last point 9 - may well make sense. They may ask for audits to be done on the methods and practices in building an effective EA But the challenge will be finding auditors with the knowledge and experience to do the auditing who are actually impartial e.g. most of the organisations that are recognised as leadings in EA seem to have unignorable conflicts of interest i.e. they are primarily vendors of systems or software; they generate huge incomes from the implementation ERP systems (often following services associated with "impartial" evaluation of ERP solutions); they don't really understand some of the issues associated with EA.

See also SOA's must be underpinned by better management

Enterprise data management

(provoked by frustration with solipsists)

In 3 years, the bytes of data generated by cameras, phones, business systems and other devices will equal the number of grains of sand on the world's beaches. While most will be consumers driven more than half is expected to cross corporate networks. Even if one just considers business data - there will be a lot of it e.g. Wal-Mart generates 1TB of transactional data a day.

Data management strategies are going to have to improve to deal with business policies, security and compliance issues. Today the average organisation can't even provide a high level map of what data it deals with i.e. it is buried in silos (often maintained by a technical clergy interested in their particular arcane way of dealing with data e.g. ER modelling, Documents, Multimedia etc.).

You can't manage what you can't see, and even if you can see it, that doesn't necessarily mean you understand it. Few organizations have a real handle on the relationship between business information/data and the underlying ICT systems that implement the data (in its many forms). Worse, if they did have visibility into the data, they would often discover that they: have several different systems handling these data; and an increasingly diverse set of internal and external stakeholders; and complex governance and compliance issues.

The end result of all this confusion is that most CIOs can't really have a candid conversation with their business counterparts about what the real issues are associated with managing todays data or dealing with more data. The typical response is to frantically try and find out where the data is (e.g. in applications SAP, Oracle, bespoke; repositories: file, data, document, content, image etc.) and then try see how hard it is access it, find it, archive it, change it, aggregate it, report on it etc.

Why hold data in an enterprise knowledge base
Some reasons for holding data in an Enterprise knowledge base are to understand:

• how the data relates to the different aspects of the enterprise e.g. what data are associated with what: process, service, objects etc. (for impact analysis, completeness checking, benchmarking against reference models etc.);
• where and in what form this data has been implemented e.g. in what systems, in what form (e.g. SQL, XML, File, Image, other etc.)
• what the business concept is (i.e. information as distinct from an implementation of if) so it is clear how it is affect by external factors (e.g. laws, compliance regulations), internal governance mechanism (e.g. life cycle management), etc.

What is wrong with the current approach
It is clear that this information can't effectively be "managed" in documents or in people's heads (often the failure of this approach becomes apparent within a business/ICT transformation project, and almost always it become apparent across projects, and time). It is clear that dedicated tools associated with various aspects of technology implementation have a role (e.g. ER modellers associated with relational data, XML modellers, ontology modellers, ETL and data mapping tools etc.). Therefore what is required is an understand of how one moves from the Enterprise domain to a technology domain.

What are the impediments
Typically the impediments to maintain an accurate view of the information/data in an organisation are:

• practitioners in one of the technology silos (e.g. ER modellers, BI/ETL modellers, XML modellers, UML modellers etc.) who can not see need beyond their immediate needs (i.e. to the broader needs of the project and organisation).
• projects which focus on the short term or a narrow aspect of the business
• vendors who have an interest in developing direct connections to their implementation technologies and thereby locking clients into these technologies.

What would an approach to establishing an enterprise knowledge base include:

• Determining the role of the enterprise knowledge base e.g. to act as a central hub tying together all aspects of what is known about an enterprise and the degree to which it will manage our knowledge of data (i.e. the conceptual boundaries between say an enterprise view and an ER view)
• Determining the nature of the interface between the Enterprise knowledge base and dedicated implementation oriented tools (e.g. ER modellers, XML modellers etc.)
• Inventorying of existing (and planned) data e.g. why it exists, who uses it, where it is implemented (systems, interfaces, store etc.)
• Benchmarking based on an industry Reference Models if they exist i.e. in some industries Industry Reference Models exist which can be used (see RHE's documents on Industry Reference models).
• Defining architectural principles e.g. what data should be implemented where and how e.g what the source of record should be, what the form of the data should be, what the life cycle issues are (and where these are governed by external compliance regulations).
• Analyzing business information for context - what drives it, who owns it, what it relates to e.g. services, processes
• Selecting data for optimisation
• Developing optimisation programme
• Integrating the data optimisation work with other programmes and initiatives
• Defining data governance approaches
• Implementating the approaches and optimisating the management of the data

[I have just used the word "data" - and have not attempted to distinguish between "data" and "information"; or "information" and "knowledge". This is not to say that I don't see that distinctions can be drawn e.g. Chambers gives the following definitions: data is - "facts given (quantities, values, names, etc) from which other information may be inferred"; information is - "intelligence given; knowledge; ...data"; knowledge is - "that which is known; information, instruction; enlightenment, learning". So from this it seems that" information can equate to knowledge or data; data provides the basis for information (which in turn contributes to knowledge); and that information and data can be stored in a system, whereas knowledge implies consciousness (e.g. people).

CIO key to business and IT transformation

(provoked by : The CIO revolution in the public sector)

If CIOs accepting this challenge will need to consider what solution(s) they need to allow them to function effectively:

• Alignment - of business and IT (how they record, and communicate, manage this)
• Visioning - forward-thinking about how ICT can enable/support achievement of the mission (technology beliefs, scenarios, initiatives etc.) and being clear exactly what roles IT plays.
• Transformations - support the nitty-gritty of this (programme definition, impact analysis, risk analysis etc.)
• Business change programmes - where IT is embedded in approval and management of all business change programmes and investment decisions are clearly seen as the responsibility of the business (how they quickly provide an accurate analysis)
• Value assessment - where proposals explicitly identify the business benefits expected and the investment required (including all: business process change, facilities, infrastructure, applications, recruitment, training, marketing and change management, etc.).

To do this they will need to work out how what their business intelligence solution needs to be i.e. that can tie together all the knowledge about their business and ICT - and present it: to specific audiences on specific topics of interest.

Some extracts from The CIO revolution in the public sector:

"...the rhetoric of business and IT alignment has to become a reality."
"... importance of the CIO role in both central and local government. ..."
"... the overall government vision for IT and service transformation but also practical developments on the ground in terms of how the IT function ..,fit[s] with the rest of the business."
"... the nitty-gritty of transformation still has to be worked out ..."
"... the capacity to engage in more forward-thinking discussions about how ICT can enable and support the organisation to achieve its broader mission..."
"... A standard process for the approval and management of all business change programmes is thus becoming more common in both central and local government. IT issues are embedded in this process from the beginning and the investment decisions are clearly seen as the responsibility of the business as a whole. ..."
"All proposals explicitly identify the business benefits expected and the investment required, inclusive of all the elements, including business process change, facilities, infrastructure, applications, recruitment, training, marketing and change management"

See also:
CIOs 'last three years
Eight roles the CIO must play - "... three roles the CIO needs to avoid: chief inertia officer, chief impediment officer and chief inefficiency officer..."
The life of a CIO: It's not pretty - "I have been to India so often that I have started to understand cricket."; "At the same time, the divisional IT guys are playing this cute game; they give great lip service to having common platforms and cooperating, but when push comes to shove -- they push and they shove."
Multiple Roles Eyed for CIOs - the CIO creates possibilities - new kinds of processes, new kinds of strategies, even new ways to reduce costs.

Business and IT transformation

SOA and EA - IBM's lessons (my summary)

(provoked by: IBM's item on EA and SOA)

My summary of the lessons
1. SOA addresses only a subset of EA domains (i.e. services) and can leverage other EA domains (e.g. information architecture, system management, operational architectures, rules/decisions architectures, function/process architectures, control architectures etc.).
2. SOA governance should leverage EA governance. The service model(s) should be developed and maintained by the SOA experts just as other aspects of an EA should be developed and maintained by their experts e.g. data/information, architecture, rules/decisionms, process arch, systems etc. The Services model(s) should be referenced from the EA and architecture review boards should consider services governance.
3. Ideally the funding models for services (and common infrastructures, and functions) should be based on an enterprise level not a project level.
4. SOA infrastructure is an enterprise asset (just like any other infrastructures e.g. information/data, rules/decisions etc.) and should be managed as part of the enterprise system management and comply with enterprise policies e.g. security.

(see also: SOA's need to be underpinned by better management)

EA and analogies with the built environment

(prompted by erroneous analogies)

EA can be seen to have a parallels with architecture in the built environment. One can examine this analogy from a number of perspectives: functions, roles, frameworks, relationships etc.

Functions

• Property Portfolio Manager - Enterprise Portfolio Manager
• Enterprise Architecture - Town planning
• Solution Architecture - Architecture
• Iterface (UI/SI) Architecture - Interior design and landscaping
• Technical Architecture(s) - Design of: Plumbing, Electrical, HVAC, Structural/Civil engineering, etc.
• Integration Architecture - Roading, Reticulation water/power/telecom, waste/sewerage
• Security Architecture - Security systems
• Developers/systems engineers - Craftsmen, artisans and construction trades - carpenter, brick layer, plumber etc.
• Operations - Facilities management and cleaning
• etc.

Roles

• Community/Town - Enterprise
• Property developer - Business owners (focused on their immediate need/benefits)
• Enterprise Architect - Town planner (focused on the broader interests over time, across all business owners)
• Solution Architect - Architect designs a solution for a business owner
• Interface Architecture - Design within constraints defined by the Architect and their detailed designs create new constraints
• Technical Architecture(s) - Develop detailed design and inform the Architect of new constraints
• Project managers (same role - different focuses) - built environments where the industry is mature and specification clear, focuses on managing plans (costs, time), change and exceptions; ICT focuses on managing scope (which is not well enough defined) and interactions between technologies and disciplines that are immature in themselves (and with respect how they interact with each other (of course they also pretend to manage plans, change, risks etc.)
• etc.

Frameworks
Frameworks that allow the different aspects of the solution to be examined (Cf. Zachman) are co-ordinate systems/map projects and measurement systems (that allow relative placements and replacements and spatial relationships to be understood), established division of work by function (lighting plans, electrical plans, floor plans etc.), etc. Frameworks define processes (Cf. TOGAF) are defined within each trade and by the overall pattern of engagement - briefing, sketch design, bulk and location, premit/approval, working drawings, supervision, as-builts etc. Frameworks which define reference models (Cf. TRMs) are defined in many codes and standards and common reference works e.g. Metric handbook (AJ Metric handbook).

Relationships
These analogies also explain the nature of the relationships e.g.

* conflicts between the immediate needs of the property developer and the broader needs of the community (and the property developers desire to circumvent constraints)
* the technician's/tradesman's views that because they know more about the detail of some technology than the town planner (and architect) the town planner (and architect) don't know what they are talking about and don't add value.
* etc.

Architecture
EA is often compared to building architecture. I think this analogy is weak if not misleading. Even if EA was like building architecture a good architect does not start from scratch. The site (slope, location, views, noise, boundaries, egress, soil/sub-soil, drainage, vegitation etc.), and its services (electrical, roading, water, drainage etc.), then there are all the codes (which codify standards of interconnection, styles/patterns of construction etc. exist). The codes make clear that even an individual building is not built in isolation. Buildings will usually be built to specific support a set of functions, an organisation, sometimes extant furnishing/equipment/plant etc. It is true that sometimes building are built to support generic functions/organisations (but these are more analogous more to OTS SW).

(This analogy could be extended considerably)

People a key factor in EA.

Many of the challenges in EA relate to people i.e. where people don't have the right motivations, capabilities, personality and background. One needs to assume of course that they are neither misologists nor misoneists (though sometimes this is hard to assume based on the evidence and the attachments to tools/mechanisms that they have long used without any obvious success - see http://ea-in-anz.blogspot.com/2007/09/ea-cant-be-done-with-document-or-case.html; http://ea-in-anz.blogspot.com/2007/08/uml-is-not-language-suited-to-most.html).

The comments below on capability and personality type come from research I have recently read.

Motivation
In many cases people don't have the motivation to see EA done properly

• self-interest: if my knowledge represents my value then why should I share it? And if everyone can share knowledge without me - why do they need me.
• insecurity: if my judgements are based partially on gut instinct (to be charitable) or blind prejudice (to be uncharitable) I don't want my judgements to be examined critically i.e. the basis on which I reach my conclusions (develop my plans and strategies).
  
• secrecy: frequently people don't want to disclose their plans or strategies because it allows people to oppose them. Usually within the organisation this is counter productive.
  
• laziness: thinking is hard, takes time and effort, and if I can wing it - then that may be easier.
  
• mypoia: I am judged based on this years projects/results (not how well it works when I am gone).

Capability or way of thinking
EA's should:

• be visionary and be able to conceptualise
• be able to analyse and problem solve
• show business acumen and be aware of situational politics
• Most importantly be able to communicate - and perhaps not annoy with their constellations of abilities ;-)

It seems that IQ is a key determinant, along with communication skills, business knowledge, problem solving and attitude towards time (i.e. re the future). Not age, intuition, technical skills.

Personality type
EA's should be: creative, open minded, passionate,engaging and resilient

Background (knowledge, skills and training)
It is useful to have had a broad background i.e. technical (hardware, software, services, applications etc.) and business (sales, marketing, operations) and to have had training in design (engineers, architects etc.) and communications. To have developed this breadth of background takes time.

To often an EA is criticized by some point technologist for not understanding the specific domain of the point technologist well enough. This is common criticism of architects generally.

The Peter Principle and EA.
When an organisation doesn't have hard and concrete measures of function (e.g. EA) the "Peter Principle" often comes into play.

Often the EA will be well respected within the Enterprise in an abstract kind of way (i.e. people will say "he knows a great deal about our business and systems", "he is very smart", "he knows lots about technology") , but not in a concrete way (i.e. "we really know what he does, what he produces etc."). This usually presents an EA who has risen through the ranks of technologists to pop out at the top. They will think that EA is little more than an extension of the technology oriented role they most recently had (e.g. SW design, infrastructure design/CMDB, Business process design etc.).

Frequently these people are ill-suited to EA based on their cognitive/personality profiles and they don't have broad backgrounds (i.e. they are essentially technologists - interested in technology).

Conclusion
To be success in EA one needs someone with the right: motivation, capabilites, personality type and background. These people are hard to find. The capabilities and personalities are very hard to change - but it is comparatively easy to provide people training to supplement gaps in their background, and it is easy to set up measures that will adjust their motivation.

James Rogers Breakfast Presentation

For those of you who missed James' breakfast sessions in Sydney and Melbourne, a copy of his presentation is available. Please email us at info@rhe.com.au for a copy.

One of his main points is that EA, and EA tools like Troux, are increasingly being viewed as a key enabler of business transformation projects. Without an aggregated view of an organisation it is very difficult to make data based decisions that span possibly multiple lines of business and IT.

From the perspective of Enterprise Architects, who often struggle for budget and to prove their value to the organisation, attaching EA to Business Transformation initiatives is a good way to prove the value of the process and to incrementally build out a view of the enterprise architecture.

James also showed us some highlights from the soon to be released Troux 7 products.

Guy

EA can't be done with document or CASE tools

To be a success EA requires the correct tooling/technology. All reputable EA experts would recognise this (though some were slow coming to this fairly obvious conclusion).

What are some of the things a tool needs to do?

The correct selection of the technology requires a clear understanding of what is required. This includes:

• Communicating- to a broad set of stakeholders (not aligned to any specific technology, and most not aligned to any technology). This requires communication in many forms (diagrams, forms, reports, documents etc.) and using many media. This in turn requires a range of publication techniques.
• Accessible - if the information held in the EA is not accessible (e.g. via a Web portal) and searchable (i.e. based on the specific, and immediate, area of interest of the person looking for information).
• Analyzable - one must be able to analyse the information (this requires that concepts and relationships are explicitly recorded.
  
• Aggregating - the EA will contain data owned by many constituencies (people and systems) and it is necessary to be able to aggregate the information from the various sources. The systems include operational systems (e.g. CMDB), design-silos (e.g. ER models, UML models, BP models), and business people (with the plans, products etc.).
  
• Maintainable - as a natural part of day to day activity i.e. without requiring any substantial additional work by any of the data owners.
• Secure - reflecting who owns the data, and who can access it)
  
• Auditable -
  
• Consistent - so that if a change is made to a concept (e.g. a business goal, a technology component) it is reflected everywhere.
  
• Integrated and cohesive - so that all connections known are recorded.
  
• Explicit and precise - this requires that the semantics are able to be explicitly recorded i.e. the core concepts and the relationships between them (their types, properties, weighting, etc.).
  
• Business oriented - this requires that languages suitable for communication with non-technical people be used (e.g. not languages just used by design people UML, ER , BP etc.).
  
• Technically connected - this requires that the EA can represent the semantics that occur in the various technology design silos (UML, ER, BP, etc.) so that explicit connections can be made to things elaborated in related tools (e.g. CASE) and eventually leads to executable code.

What about people who say it can be done without tools?

If an EA professional advocates doing EA without suitable tooling - I would characterize it as unprofessional i.e. either they are ignorant (of what EA is, and what is required to achieve it) or they are being disingenuous (i.e. they know what is required, but don't see it in their interest to make it clear).

By way of comparison - if someone's profession was creating complex models in another domain e.g. large project plans, complex budgets, complex building design - they could not (in any of these domains) credibly advocate doing this just in say Powerpoint, Word or Visio (and at the same time claim to know a great about project planning, budgeting, complex building design).

What about an Office suite as a tool?

EA tools must have the detailed representation of information that BI requires, have the communication and ontological capabilities of knowledge management tools, be able to support the detailed semantics required for connection to dedicated design domains, and be able to graphically communicate complex designs.

Office suites fail for reasons such as:

• Communicating - Documents can't practically be produced for each and every stakeholder focusing on the small subset of the information they are interested in at any point in time, and presenting it in precisely the way they want to see it (diagram, forms, report, chart) etc.
• Analyzable - Documents (Word, Powerpoints etc.) can't be analysed (except by people)
• Aggregating - Documents don't lend themselves to aggregating data.
  
• Maintainable - no one can credibly suggest that all data held in documents is practically maintainable.
  
• Explicit and precise - Documents seldom explicitly record all the relationships within them and never record all the relationships across concepts held in sets of them.

The information from an EA should be able to be conveyed via documents (from Office suites). In this sense these documents (Word, Excel, Powerpoint, Visio etc.) represent reports. However the fact that reports are required does not mean that the reports themselves are the locally repository for the data.

What about CASE tools?

People' who start looking for EA solutions by asking about CASE capabilities - indicate that they have not understood the essential nature of the problem see:
http://ea-in-anz.blogspot.com/2007/08/business-modelling-with-domain-specific.html
http://ea-in-anz.blogspot.com/2007/08/uml-is-not-language-suited-to-most.html