Friday, September 28, 2007

Insights about Content Management challenges

"Culling Content Management" by Alan Pelz-Sharpe:

"It's long been a gripe of mine that ECM systems were designed to reduce the amount of content you needed to manage to essentials. Yet instead they often just manage everything - trash along with diamonds...//...It's really not that hard to reduce the volumes of content you manage dramatically - a simple content audit can clear out 70-80% without in anyway impacting your RM policies or frankly even being noticable to the end users. Most everything sitting there anyway is a duplication, is redundant or should never have been there in the first place."

"There once was a firm in Nantucket..." by Bob Larrivee at AIIM:

"If your information management and gathering effort is called into question, you may be asked to prove that you have policies and procedures in place that are followed by your employees, using a consistent structure and taxonomy for storing and managing information that is also tracked for purposes of auditing and reporting."

"Strategies for Improving Enterprise Search - Beyond the Out-of-the-Box Experience" by John Ferrara:

"It’s common for enterprise website developers to implement search engines with out-of-the-box functionality, point it at their content repositories, and then just leave it at that. Search is becoming something of a neglected orphan, in part because packaged search products are relatively easy to implement, and then even more easily forgotten...//...Quality search results only come about through applied effort, requiring in particular the skills of an information architect. And IAs must be ready to go well beyond their traditional front-end role, digging into the functional backend and source data of the search engine."

Wednesday, September 26, 2007

Hype shopping

2 years has passed since the last time I helped a client buy a software application. I expect the process to be very similar this time with the main difference being that there will definitely be discussions about Web 2.0. This time around it is an educational platform that is considered by my client making the new collaborative techniques even more attractive. One might even argue that a lot of the development around new collaborative software has sprung from the needs of the learning community.

I think that the hype the last couple of years has effected how and what the companies buy and especially how they prioritize their requirements. It is always a risk in a project like this that new hyped functionality will get to much attention and be considered as the number one priority feature which of course it's not.

Due to these circumstances the requirements sessions in this project will be especially interesting to facilitate and the questions asked by Oscar Berg in a posting last week will be as relevant as ever before. More postings will follow on the subject throughout the purchasing process.

Monday, September 24, 2007

Are Microsoft over-complicating things with SharePoint?

These two posts about Microsoft SharePointare basically saying the same thing , but with completely different intentions.

Why SharePoint Portal Server is Terrible:

"SharePoint is a great idea; it was just built completely wrong. It's a perfect example of trying to build something that does everything, making the software so complicated that it is so hard to use, that it is useless."

MOSS: Effective introduction to an Organization:

"MOSS is such a big animal ... it includes content management, document management, search, security, audience targeting, project management, "fabulous forty" templates, workflow, business data connector, etc. Couple this with the fact that it's a large organization that can truly make use of virtually every major MOSS feature and you have the makings of a great project with an enterprise reach and many good things happening. We're confronted with this issue time and time again ... MOSS has an enterprise reach with its enterprise feature-set, yet even somewhat sophisticated clients have a hard time mentally absorbing those features, let alone incorporating an appreciable fraction of them into their daily routine."

Friday, September 21, 2007

The Curse of Portal Software

A portal provides unified access to a collection of services and content resources. The main purpose of a portal is to simplify for users by making everything they need readily available at their fingertips.

Portal software vendors often emphasize the “everything” word in the sentence above. There's nothing strange with that. Software vendors have always had number of features as their main sales argument. But, as a software buyer you must see through this and realize that simplicity is the most important attribute of any software. Complexity typically increases with the number of features and the challenge is therefore to balance features and simplicity.

Involving users and eliciting requirements from the intended user population is a key success factor for a portal initiative. The portal must serve the needs of the users and what is better then than to ask the users which their needs are? Well, there is one thing to be cautious about when involving users – users always know what they want but not always what they need. Many users think they need a lot of features just because they want a lot of features.

The quest for simplicity requires someone to take the role as the devils advocate, to confront the “wants” (that everyone might agree on) to see if they are backed up by real “needs”. To prevent compulsive shopping of portal features, you should make everyone who wants a feature on the portal answer the following questions:

  • Will I use it?
  • Will it simplify my life?
  • Will I be happier with it?
  • Can I afford it?
  • Will it be worth the money?
  • Would I rather spend the money on this than on something else?

If the user can answer "Yes" to all of these question, you should continue to see if there is a business value to implement the portal feature.

But bear in mind that humans are like hamsters, always collecting everything. And the life of a hamster is not always simple.

Thursday, September 13, 2007

What is Enterprise Architecture?

If you ask five persons, “What is Enterprise Architecture”, will you probably get five different answers depending on their background. My answer is that Enterprise Architecture is a way to support changes of Enterprises.

If you instead ask them, “What is architecture”, will they come up with similar answers. Architecture is for most of us are synonymous with the Opera house in Sydney, Petronas Towers in Kuala Lumpur or La Sagrada Familia in Barcelona. It could also be our office where we work or our home where we spend a large part of our lives. The term architecture is for all of us tightly coupled with buildings or cities.

The fact that successful architecture needs a proper design and thoughts before starting the construction may not be aware to us before we try to renovate our own house. Architecture is the art of matching requirements with constraints in complex situations.

This is why the description of Enterprise Architecture should be to design an Enterprise so it can produce and deliver products and services to their customers. But an Enterprise is seldom built from scratch. It is more like an old house that have be build out during different time periods to fulfil the different needs of the owner. This is why the title for series of articles is The Changing Enterprise. Without changes in the surrounding environment, there is no need for major changes within the Enterprise.

One the other hand, without Enterprise Architecture an enterprise will probably fail if a major change in conditions occur. It will meet the same fate as the dinosaurs.

Enterprise Architecture is first of all a way of controlling change in a predictable manner and migrating risk. Second, it is also about creating support for more efficient ways of working and improving operational efficiency. Third and last, it is an enabler for new business opportunities with the help of Information and Communication Technology.

In order to achieve this in large complex organization, Enterprise Architecture has to handle questions about organization, processes, information management, applications and technical infrastructure.

EA is therefore not a technical issue for the technology department, but instead an important question for the CEO.

Wednesday, September 12, 2007

ECM Illustrated - Data and Content Management will blend together

Enterprise users need accurate and complete information in a timely manner to do their jobs. The information they need is often located in different content sources and with different degree of structure. To satisfy the information needs of the employees, an enterprise does not only need to integrate content in different content sources to satisfy information needs, but also integrate structured content (data) with unstructured content.

The world of Data Management has until recently been separated from the world of Content Management, with suboptimization as a natural result. The separation of Data Management and Content Management has its roots in that structured content has traditionally been stored in databases and that unstructured content has been contained in documents and files stored in file systems.

Below is a simple way to illustrate the original positions of Data Management and Content Management and how they will eventually blend together.




From a user perspective, it does not make much sense to treat structured and unstructured content as two separate things. What matters to the user is that he/she can find and access all relevant content and that it gives just enough context to efficiently extract all the information that is needed from the content.

From a business perspective, it does not either make much sense to treat structured and unstructured content as two separate things, even though structured and unstructured content needs to be managed in more or less different ways. The primary concern of the business is to fulfill its goals and to do so it needs to enable the employees to carry out the activities needed to fulfill these goals. One important aspect of this is to supply the employees with just the resources they need, such as content resources from which they can extract the information they need. To treat Data Management and Content Management as two separate things would be as dividing a football (soccer) team into a defensive team and an attacking team and let them play independently of each other. It would be an interesting game to watch, but a sure loss for the team(s).

Monday, September 10, 2007

The Changing Enterprise - Preface

The main reason for Enterprise Architecture is the Changing Enterprise. The environment the Enterprise exists in evolves and puts new demands on the existing organisation. Enterprise Architecture is about mastering changes in a predictable manner.

This series of articles will give an introduction to Enterprise Architecture towards stakeholders inside and outside the organisation. They will cover a number of topics in a straightforward way to give the readers an understanding of the challenges with change.

Preface
1. What is Enterprise Architecture?
2. The value of architecture
3. How well do we perform?
4. What is good enough?
5. Remember the customer
6. What do we need?
7. EA governance model
8. EA process
9. EA framework
10. EA tools
11. Abstractions levels
12. Iterations
13. Prerequsite for Enterprise Architecture
14. Conclusions
References
Biography

Welcome to share my thoughts.

Casimir Artmann

New Blog Contributor - Casimir Artman, Enterprise Architect

I am happy to announce that Casimir Artman, Enterprise Architect specialized in Telecom, has become a contributor to The Content Economy blog. He will post a series of articles about Enterprise Architecture.

What Characterizes the SaaS Software Delivery Model?

How do you quality a software vendor as a SaaS vendor? They might call themselves that, but are they really keeping the promise?

The definition of SaaS is quite fuzzy, but here is an attempt to list some of the key characteristics (some of them from Wikipedia.org) of SaaS as software delivery model:

  • Commercially available software
  • Multiple customers run the same software (instance) but with virtually separate data stores
  • Accessed remotely via the Internet
  • Rich application interface
  • Centralized updates
  • Frequent updates possible without disturbing the service
  • Designed to be scalable
  • Well-defined and documented API
  • Adaptable by configuration
  • Extensible to customer-specific needs
  • Adaptions and extensions can be done by customer or third party supplier
  • Supports reuse by application exchange
  • Tools are available for operating, monitoring and control
  • Customers pay for their consumption and not (in advance) for the development of the service

Friday, September 7, 2007

Defining The Workers

What is the difference between an information worker and a knowledge worker? Are there any differences? Some argue there aren't, that it is confusing to talk about information workers and knowledge workers. Maybe so. But with the basic definitions of information and knowledge sorted out, it is in fact possible - and desirable - to make a distinction between information workers and knowledge workers. Here is an attempt.




The Information Worker

  • Defines the message that the content product is to transmit to a specific audience.
  • Decides what needs to be said, to whom, why it needs to be said and what effects the message should give.

The User Experience Worker

  • Defines and designs the content product and what overall experience that the audience should get when perceiving and interacting with the content product, including everything surrounding it that might affect this experience.

The Content Worker

  • Defines and creates the format and components of the message so that it can be produced, managed and delivered efficiently and securely to the right audience.
  • Decides what types of content to use for encoding the message, if/what existing content that can be reused and how it shall be described.

The Data Worker

  • Works with the smallest pieces of content used for the content product (“facts and figures”).
  • Ensures that the data are made available for producing, managing and delivering the content product.
  • Focuses on efficient storage and retrieval of (usually) large volumes of data.

The Knowledge Worker

  • The intended receiver of the message, the consumer of a content product.
  • Perceives, interprets and tries to understand the message from the content product as the receiver intended it to be understood.
  • Reflects on and applies the message to achieve business (and/or personal) objectives.