[ About Info|Ed ] [ TiAC ] [ What's new at Info|Ed and TiAC ] [ TiAC White Paper Repository ] [ Information Architecure Resources ] [ White Paper Request ]

TiAC: Information Architecture Round Table

The discussion throughout the two days was wide ranging. Therefore, I have very briefly summarized the four sessions and reserved the analysis for a second section where I have pulled together some of the themes that I saw in the discussions.

Summary of Sessions

Critical Success Factors

_________ reviewed what he found the critical success factors in attempting to develop a corporate information architecture based upon his four years in the role. This provoked a discussion on mission, charters, and identifying the key tasks each of the group saw themselves undertaking.

The Critical Success Factors identified were:

Issues driving companies towards architecture:

More components to manage independently

The burden of maintenance

Business Architecture

__________ of ________ talked about the challenge of keeping the attention of executives who are not directly involved in the technology. This found a chord in others who saw themselves providing the link between the business vision and the technology. It became clear that some of the group were taking a more formal approach to modeling than others but there was a concern if overly technical and analytical language was in fact a barrier to communication.

____ pointed out the significant cultural issues the bank faced in bringing in an architecture. Getting buy-in from middle management was a problem faced by many together with resistance from business managers who have to deal directly with the technology for the first time.

The issue of retraining was raised. Current jobs were going to disappear, especially in I/S, and some new ones created but requiring new and different skills. One company reported problems in retraining I/S professionals to master the facilitator role of the data modeling task. This started a discussion of what jobs the majority of I/S workers would be easily retrainable for. The change from knowledge worker to facilitator was a major change, whereas moving from one technology to another was less radical. Aptitude and desire for a job were as important as skills.

Technical Architecture

_________ discussed the architecture effort at _______ and the organization of his group. There was an emphasis on getting management support and involving as many individuals as possible. The core team at _______ is small, only four or five people, but many more participate in a continuing process.

____ led the group through a process that exposed what they saw as barriers to implementing a technical architecture. (The result of this exercise was circulated earlier in a paper called Barriers.) Problems with technology were identified, but the greatest area of concern was the degree of culture shock that was implied by the architecture, both to the business areas and also to the I/S organization. There was a feeling that the degree of change that is implied is not understood by the majority of I/S professionals and managers.

Implementation

__________ of _________ discussed developing an architecture for manufacturing, where the systems are an integral part of a plant costing hundreds of millions of dollars, upon which the company depends. Janet described a time driven process where the architecture development has to match the commitment of technology to a facility. This integration of systems with task was recognized by others in areas outside manufacturing and was accepted to be changing the nature of MIS fundamentally.

_______ discussed some of the techniques that _____ uses to measure the effectiveness of its architecture efforts. ______'s model is based on a three component model: product worthiness, usability and evolvability. Applying measurements to architecture was an area that people wanted to address at a future meeting.

The group reviewed the critical success factors and looked at the implementation process. Four phases were identified: commitment, development, deployment, and support. A group looked at each of these and reported out. A summary is attached.

Action Planning

The last session was spent looking at the group process and planning future sessions.

It was agreed that the group should meet regularly and that this first meeting had been the right length. Some suggestions were made for building on this. There was a general agreement that the success of the group depended on getting to practical issues of process and substance. This would involve studying companies in more detail and getting more discussion going.

There were comments both for and against using the group to develop common solutions or approaches. The consensus was that the group should concentrate on sharing information as it was easier to get agreement as that level. Only companies with very similar goals were likely to be able to achieve any degree of partnership.

There was general agreement that this group could be the basis of a very effective support group.

It was agreed to meet in September/October, date and location to be agreed.

Info|Ed and the steering committee were asked to look at a more formal constitution for the group and to get back to the whole group.

Themes

Shared language

Did everyone mean the same thing when they used a particular term? In general, the answer to that has to be no. When __________ talked about Business Architecture this was very different from the data and process models that, for example, Digital would understand by that term.

Did this variation in use of language inhibit information exchange? Yes, but not, on this first occasion, disastrously. Resolving this ambiguity will be a challenge because of the different bases from which individuals come to Information Architecture. Two sources were identified - PRISM and John Zachman. _______ has looked at both and has not been able to resolve them.

Two question suggest themselves. First, is IA a well defined term? We seemed to coalesce as a group with shared objectives, so at the lowest common denominator IA is well defined. However, there was far more divergence over the content and boundaries of IA. It appears that the process followed and tasks undertaken in two organizations may be very different. Therefore the second question, "Is there a shared vision of IA?", is less easily answered in the affirmative. I believe that this area of language will continue to exercise us at future meetings.

Also, we need to develop a working language-the word 'models' had different meanings for people. We talked about four phases in implementation and perhaps those will be useful subsequently. If possible we should keep to common usage and avoid inventing language.

Methodology

No one was prepared to claim that they had a robust methodology. Issues of completeness and quality were referred to throughout the two days. ____ _____'s work on metrics has already been mentioned, but few others had attempted even this much.

Current practices were compared unfavorably with engineering processes. Typical questions were: What should be included? When will we know if we are done? Are results reproducible? This engineering analogy focuses on completeness. Indeed, what would be the contents of the Information Architect's Handbook, if such a reference tome existed?

An alternative reading of this area could emphasize the dynamic innovation in technology and process that organizations are undergoing. Maybe the task of Information Architecture itself is changing. Or, even if the core of the task is stable, the expression of that task in terms of the artifacts created through the process is evolving rapidly. For example, new technologies may require or suggest an emphasis on particular types of analysis and modeling. If this is true, any attempt to develop a comprehensive manual could prematurely freeze development.

Certainly there is a need for guides and tools for evaluating progress towards the agreed goals, to present the range of tools available, and to allow review of plans based upon current best experience. An example of this approach is the "Body of Knowledge" document put together by the Institute of Project Management. This concentrates on identifying what issues and disciplines fall within the domain of project management, without trying to lay out a single process or methodology.

Metrics

One specific methodology issue raised was establishing metrics. This is a many sided problem covering baselining current performance, establishing goals and measuring performance. Neither can metrics be separated from justification of IA.

We saw examples of metrics from _____, and others mentioned some they were doing. We need to collect more data to see what everyone is doing and if there is any basis for comparison. I suggest that we start work in this area for the next meeting.

Flexibility

I believe it is fair to say that everyone present agreed that traditional systems development practices led to systems that were not flexible enough to serve the needs of the organization as those changed over time. There was less agreement on what flexibility is, or what to do in an architecture to lead to more flexibility.

One aspect of flexibility is the organization's attitude to open systems and vendor independence. Concern was expressed about hardware, operating system, user interface, DBMS and application software dependence. One approach avowed was to identify critical standards and to select packages and vendors that supported them. A second strategy was to look for middleware that would support as wide a range of standards as possible to make application coding independent of the underlying technologies.

It appears to be a case of choosing your poison: independence through standards or independence through dependence on a middleware, operating system, or DBMS vendor. It comes down to a question of values. This is one area where it would be worth identifying and studying the strategies each of you have adopted. At least it would help us better understand each other.

Legacy

This is the test by which all architectures and plans must be judged. Everyone had legacy systems and everyone was concerned whether they had legacy people. There was concern about finding the right solution to both problems.

There are three generic strategies for legacy systems: rewrite from the ground up, restructure existing code to make it viable in the future, and "surround" strategies for preserving key databases and processes within the new environment. (The term embalming has been suggested as more accurate than surrounding.) Each of these general strategies has to be developed into a set of processes to accomplish the task for each system or class of system. It was not clear how far most companies had proceeded in any of these approaches. At a minimum there is a growing set of case studies to share and review.

How to respond to changes in the mix of I/S skills required in the future provoked discussion. The question of whether dealing with these consequential issues fell within the realm of IA was raised. I suspect that for some organizations managing this transition is an input to the choice of technology, while for others the problem is dealing with the fallout from choosing the most appropriate technology. Largely our discussion highlighted a high level of concern, but not necessarily a lot of facts upon which to base decisions. It would be useful to scope the scale of the problem by having each member project the future profile of the I/S work force and review those projections annually or semi-annually.

Commitment

Listing Critical Success Factors this came at or near the top. Building and keeping management commitment to the architecture was identified as key to perhaps every process discussed. This reflects the degree of coordination across functions and the relatively long timescale implied. There is a question as to whether this issue has truly entered senior management's consciousness and the degree to which it can be picked apart.

Architecture necessarily is an integrating concept: it attempts to pull together related issues to show how they interact and the need for a solution which manages to address all these issues. However, as events mature, there is always a tendency to try to pull apart that package and to only push forward on specific hot button issues. Commitment, then, is not only agreement to the plan but a willingness to hang in when the decisions get tough.

Obviously, each company has tried to address this issue as best they can. One question is, what are sufficient conditions for architecture to be an issue for which management will go the distance? These could include maturity of technology, strategic importance of IT, technical sophistication of senior management, experience with similar programs, and clarity with which architecture issues are separated from general IT concerns.

Conversely, ____ ____, in his presentation, was clear that the issue brought to management was not described to them as architecture; architecture was only a named action point for dealing with the issue. Is this in fact the normal case and architecture only one program under a strategic umbrella?

Implementation: Commitment

Assumptions

Version 1 Architecture exists
Architecture Organization is in place
Steering Committee

Continuously sell

Implementation: Development

Assumptions

All prior steps done perfectly but still dealing with uncertainty and risk because the future is unknown

Issues

Implementation: Deployment

Implementation: Support

Assumption

The biggest issue in support is when the World changes:

Choice of ad-hoc response or Re-design

Entropy first leads to non-conforming implementation for tactical reasons; how does this then lead to evolution and re-design?

How do you not have the attitude that the designer is convinced they have defined the perfect (entity, ....) Need to keep architecture flexible.

Meetings

Comments from the group on meeting format