Envisioning and shaping the future of work and business.

Wednesday, October 31, 2007

Enterprise 2.0 and the shrinking IT department

9:59:00 AM Posted by Oscar Berg , 1 comment
The IT department needs to shrink for its (or IT’s) own good. There is no paradox in increasing the use of IT in an enterprise and shrinking the IT department. Rather, it is a necessity for an enterprise to do so in order to use the full potential of IT. Even the need for IT experts will decrease. But, the need for people that combine business skills with a deep understanding of IT will increase.

This reasoning makes sense if you accept that there really are no IT projects, only business projects with more or less IT involved. Even an upgrade of a mail server is done for some business reason. In such a reality, IT experts that lack a business mindset do not function very well. Nor does an enterprise that relies on these persons to make or heavily influence their decisions about IT. You don’t necessarily need ROI calculations for all IT investments since an enterprise sometimes need to take chances and try things out (in small scale), but you always need strong business reasoning backing up all decisions about investments in IT.

In many (most) enterprises there is a void or gap between the business side and the IT side. Just the fact that we often talk about “the business side” and “the IT side” implies that it exists. The solution to close this gap is not for the IT department to send out ambassadors or infiltrators to “the business side”. Instead, the business side should recruit people with a deep understanding of both businesses and IT. The real change must happen on the business side.

To me, this is partly what Enterprise 2.0 is about. For an enterprise to quality as Enterprise 2.0, the majority of the business people must not only understand the potential uses of various information technologies but actually anticipate, explore and adopt those that can improve the way they work and do business. Web 1.0 became Web 2.0 for the same reason. Instead of passively and anxiously watching what business and early adopters are doing on the web, a majority of the users now understand how the web can be used and actively contribute to the life, growth and development of the web. Enterprise 2.0 is about business people driving IT initiatives instead of the IT department trying to drive or control the business. Or put in another way, Enterprise 2.0 is about making IT an inherent part of all business.

Tuesday, October 30, 2007

Gartners Magic Quadrant for Team Collaboration and Social Software 2007

8:54:00 PM Posted by Oscar Berg , No comments
Gartner released their first Magic Quadrant report on the Enterprise Social Software market last week:
"The collaboration support market is being revitalized, with buyers and sellers looking to add social interaction in the context of broad collaboration support. We map how new and established vendors focusing on teaming, communities and social interaction are positioned in this changing marketplace".

The Magic Quadrant graphic can be found on the SocialText blog. SocialText is one of only two vendors who (barely) made it to the "visionaries" quadrant. No vendor made it to the "leaders" quadrant.

Taxonomies and tagging in MOSS 2007

Although MOSS 2007 has many benefits, two of its most apparent weaknesses are its lack of built in support for creating taxonomies for document classification and for tagging documents with user-defined tags.

I have been exploring Microsoft’s SharePoint site and MSDN forums about Social Computing and Enterprise Content Management and can conclude that I found virtually nothing there about taxonomies and tagging. The most interesting information I found was a forum post called “Document Classification Taxonomy in MOSS 2007” which describes a typical business use case that can be supported by classification taxonomies:

“We have approximately 300 different document classifications and we could create a content type for each, but this would require users to scroll through a list of 300 options every time they upload a file. This is not particularly friendly. What I would like to create is a mechanism whereby users, upon uploading a document, are asked the basic nature of the document."

The only answer to that post recommended to either add 300 content types and use many document libraries or to look at a third party tool such as RAPID that I mentioned above.

My exploration of Microsoft’s ECM blog did not either result in much. What I found was a single post from early 2007 (by Adri Verlaan, a developer on the ECM team) which introduces a “Tagging Starter Kit for SharePoint Server” including a “lightweight working prototype”. I quote:
“Currently, the kit allows authors to attach tags to content and readers to specify tags in which they are interested. Using this information for a specified content source, a customized Content Query Web Part shows only the items that match a reader’s respective tags. “

In other words, there seems to be little about taxonomies and tagging from Microsoft. But, are there 3rd party tools available to make up for this weakness? Well, KWizCom recently released a third party product for MOSS 2007, called “SharePoint Tagging Feature”:

“KWizCom SharePoint Tagging Feature enables the tagging of SharePoint content such as documents, list items, pictures, forms etc. Furthermore, with the included Tag Cloud Web Part, SharePoint Tagging Feature enables many new capabilities such as presentation of items according to tags, tagging e-mail alerts, and more..”.

To add support for taxonomies, there is “RAPID for SharePoint” from Artemis Corporation:
“The RAPID 'Taxonomy' Classification framework allows the application of any taxonomy within SharePoint content. An unlimited number of taxonomies can be
created and used within a site to classify documents and list items. Once classified documents and list items can be filtered, indexed and queried using standard WebParts, List Controls and Views. Fully integrated into Microsoft Office SharePoint Server 2007"

It is hard to tell from these descriptions how capable these 3rd party tools are. If anyone has had hands-on experience of these or equivalent tools, please share.

Monday, October 29, 2007

Web 2.0 – A true Internet revolution?

10:54:00 AM Posted by Oscar Berg No comments
Many of the technologies that are related to the concept of Web 2.0 are not new. Wikis and blogs have been around for several years and the same is true for social software. What is new, however, is how they are being used. They are being used in new and innovative ways and - more importantly - they have been accepted and embraced by the masses. In a sens, the Internet revolution that so many talked about in the dotcom years has become reality. Web 2.0 could not happen until a critical mass of users showed enough willingness, trust and openness to participate in the further development of the Internet and the web. The web has become a public square where people can meet. Businesses might see it primarily as a place to make transactions and earn profits, while many people instead see it as a meeting place that they can use as a means for self-fulfillment.

Interestingly, the primary business model on the web is based on selling advertising space which is primarily used for marketing consumer products. This is the paradox of Web 2.0. Even if people are really starting to change how they use the Internet and the web, no one should be surprised if Google and Facebook will suddenly stop showing outstanding growth and profit numbers when the business cycle reaches the next recession. When people don’t feel confident enough about the future to buy a new flatscreen TV och refridgerator, it will eventually hurt Google and Facebook badly. Hence, a true Internet revolution will in my eyes only only come when the primary products that we consume (accounting for the biggest part of our consumtion) are intangible digital content and experiences. Then the Internet can become the engine that drives the global economy, just as the industry once became more important than the agriculture for the national economies.

Thursday, October 25, 2007

Is there a Business Case for enterprise social software?

11:07:00 AM Posted by Oscar Berg No comments
I believe the business case for enterprise social software is obscured by the discussion about whether or not you can and should calculate and measure the ROI for enterprise social software. In this discussion, there are those (including me) who argue that it is problematic to talk about ROI for social software, as Joe McKendrick:

"The problem with Web 2.0 and Enterprise 2.0, of course, is that the benefits delivered are “soft” benefits; there are few examples of hard numbers to show ROI.

Luis Suarez shares a similar option about trying to calculate ROI for social software.
“If social computing is supposed to revolutionalise the way we share our knowledge, connect with others, collaborate, communicate and innovate, then I think it is about time we move into the 21st century, progress further in that Knowledge economy and try to figure out how to get the most value out of it, because figuring out its ROI, in my opinion, is going to be a waste of time, energy and resources.”

As modern humans and rational beings we are addicted to cause-effect relationships. Decisions based on intuition (experience) are always lower graded than decisions based on hard facts, even if they turn out to be the right ones. Improvements that happen, but where we cannot put the finger on what caused them are hard to accept as improvements (if you haven't read the book "Blink" by Malcolm Gladwell, you should).

Even if you can’t put numbers on what you expect to gain from using social software within an enterprise, you should be able to make a strong business case for it. The idea with a business case is to establish benefits and desirability of an initiative that aim to resolve a problem or grasp an opportunity. If the potential benefits can be argued to justify the costs of the initiative, why not go for it? It is easy to be fooled by facts, numbers and figures. They are often very convincing, but is there always a strong reasoning behind them? No, not when you look a little closer, behind the seemingly convincing figures.

To me it is obvious that the old way of organizing ourselves does not lend itself very well to how we need to work and collaborate in enterprises where information and knowledge are key resources. Hierarchy (bureaucracy) has been the dominant organization paradigm in the industrial era and still is, even if it is obvious that we need to organize ourselves into networks to collaborate and exchange information and knowledge efficiently. Social software present a golden opportunity for enterprises to move to the network paradigm as they have already proven to work outside of enterprises for establishing and nurturing social networks.

Wednesday, October 24, 2007

Enterprise 2.0 vs. Web 2.0 (Chicken vs. Egg)

Some say the web is evolving into another version, often called Web 2.0. Others talk about the evolving Enterprise, and use a similar 2.0 appendix. New technologies enable new ways of working and fresh ways of working lead to technology innovations. Often it is difficult to pinpoint what is the chicken or the egg in this creative process.

How to define Enterprise 2.0 and Web 2.0? Depending on whom you ask you will most likely get different answers. Useful perspectives in understanding the Enterprise/Web 2.0 phenomenon are:

  • Business: Leaders of the Enterprise 2.0 movement are aiming for business models that are agile, open, distributed, on demand etc. These concepts are supposed to contrast to traditional hierarchical and bureaucratic organizations managed using order and control mechanisms.
  • Technology: IT people promote that services and content can be reused and re-purposed using techniques such as Feeds, File Sharing, Mashups, Web Services etc. Ajax (Asynchronous Javascript And XML) is the main driver behind a richer web user experience. User generated content and metadata are produced via Wikis, Blogs, Folksonomies and the like.
  • Human: The consumer (end-user) seems to be the king when it comes to adopting new practices and technology. Current social trends embrace more open collaboration where content is created and shared in self-organizing networks and communities.

One key question for Enterprises is how to utilize these emerging business, technology and human fields. Many enterprises are probably eager to implement Web 2.0 technologies, but will the technologies bring the desired benefits without implementing the business and human fields? Enterprise 2.0 evangelists will probably have difficulties in realizing their business visions without the technology and human fields.

So, which came first, the (Enterprise ) Chicken or the (Web) Egg? Without being to philosophical I think we can conclude that the chicken and the egg are interlinked and mutually dependent on each other for survival and wealth.

Tuesday, October 23, 2007

Open Text product launches reveal new strategy

9:18:00 AM Posted by Oscar Berg , , No comments

"Content Services form the basis for Open Text’s next-generation content management framework and takes a unique, repository-agnostic approach to ECM, thereby eliminating the content and process silos created by different business systems by detaching the information worker experience from the underlying content repositories." (OpenText)

Open Text has just launched three new ECM products: Open Text Enterprise Connect, Open Text Enterprise Process Services and Open Text Enterprise Library Services. In other words, Open Text is splitting up their Livelink ECM product into several collections of services to be used for content management within enterprises. I personally believe it to be a smart (and necessary) strategy for an ECM vendor. It potentially means that customers only interested in implementing basic content services such as library services and want them to be a part of their enterprise infrastructure, or want to start implementing those before adding more advanced ECM services, can choose to do so. They can be used to support the entire range from ad hoc performed content activities to structured content processes. For the latter, the customer can implement Open Text Enterprise Process Services. Or they can implement process services from another vendor. It is a move away from monolithic (or fragmented) ECM products and a step into the service-oriented world.

The cynic in me wanted to write something about potential issues related to such things as compatibility and integration in this post, but I chose not to listen to him this time.

Reading Tips - The State of Enterprise 2.0

8:13:00 AM Posted by Oscar Berg , No comments

Dion Hinchcliffe has written a good post on "The state of Enterprise 2.0" where he provides a good overview of the current state of Enterprise 2.0. I personally like the learnings about Enterprise 2.0 that he shares in the post. They deserve to be cited in a somewhat more condensed form:

Lesson #1
Enterprise 2.0 is going to happen in your organization with you or without you.

Lesson #2
Effective Enterprise 2.0 seems to involve more than just blogs and wikis.

Lesson #3
Enterprise 2.0 is more a state of mind than a product you can purchase.

Lesson #4
Most businesses still need to educate their workers on the techniques and best practices of Enterprise 2.0 and social media.

Lesson #5
The benefits of Enterprise 2.0 can be dramatic, but only builds steadily over time.

Lesson #6
Enterprise 2.0 doesn’t seem to put older IT systems out of business.

Lesson #7
Your organization will begin to change in new ways because of Enterprise 2.0.
Be ready.

Hinchcliffe also encourages his readers to add their learnings and here are a few of mine:

My Lesson #1
Enterprise 2.0 is about users driving business improvements with IT and thus has the potential of becoming a true IT revolution.

My Lesson #2
Enterprise 2.0 can leverage existing IT systems and bring valuable content up to the surface.

My Lesson #3
Enterprise 2.0 builds on the importance of finding the right person(s) and not only the right content to get hold the information you need.

My Lesson #4
Enterprise 2.0 is about putting user needs first - acknowloging that we are social creatures - to make the business more productive and efficient from grass-root level and up.

Monday, October 22, 2007

MOSS 2007 is missing the point with web 2.0

7:42:00 AM Posted by Oscar Berg , , No comments
When introducing web 2.0 technologies for enterprise use, it is important to understand why web 2.0 technologies have been adopted by the masses. Web 2.0 is more than a bunch of new technologies – it represents a new paradigm in how people think and behave in how they use information technology. Much that was said about the web in the dotcom days (“the Internet revolution”) are actually happening today. Technology-wise, not much is new since the dotcom years. What is new is that the masses have adopted modern information technology and the Internet and practically made it to their own. Today, people are often faster at adopting new technologies than companies. They bring consumer technologies to work, they want to choose their own productivity tools (and do so) and see IT as a business thing rather than an IT department thing. To most people, IT is no longer an obscure thing.

So, back to what (I believe) made people finally adopt all these technologies. First of all, it has to do with the fact that people have a more relaxed and natural attitude towards information and technologies and the Internet today than they had a number of years ago. They are familiar with it. The barriers to adopt new technologies are lower. Secondly, the applications are much more user-oriented. They are aimed at serving the needs and wants of humans, not businesses. And – not the least – they are simple to learn and use.

In the hands of the old enterprise software giants, web 2.0 easily becomes a complex thing. Their ambition to extend and modernize their feature-packed software suits with web 2.0 applications and technologies might cause them to miss the whole point of web 2.0; the ease of use. At work, I am using MOSS 2007 and Microsoft Office 2007. Privately, I mostly use Google apps such as Docs & Spreadsheets, Blogger, Gmail and Calendar. The biggest difference between them is the ease of use. Blogging within MOSS 2007 is a disappointing experience and so is managing and collaborating on documents. Google’s Blogger and Docs & Spreadsheets easily beat them both (even though the Docs editor sucks). To be able to set up a blog in MOSS 2007 for a collaboration site, I had to go in to the obscure “Site Settings” section where I was overwhelmed with choices and strange terms. Sorry, Microsoft. You are missing the point with web 2.0. It is not about adding web 2.0 technologies such as blogs, wikis and RSS to your product specs. It is about ease of use and thinking like a user when you design a product. Office 2007 is certainly on the right track, but not MOSS 2007.

Thursday, October 18, 2007

Allowing Chaos in Content Management

7:07:00 AM Posted by Oscar Berg , , , No comments
Content management is not about moving from chaos to total order, from anarchy to total control, from ad hoc to highly structured ways of working. For an enterprise to work, you have to mix and match; give a little freedom here, add a little control there.

What I am saying is that there is no paradox in providing users with the freedom and power to create, tag and share their own content and communicate and collaborate with others as they desire while governing and controlling the production and delivery of content assets. It is just a little bit harder than to either give total freedom or take total control. Because the easy way out to tackle content management challenges is either to do nothing or to put everything under central control.

For example, an organization would probably benefit from having both user-driven metadata (folksonomies/social bookmarking) and centrally developed and managed metadata such as enterprise taxonomies. Why? Because they serve slightly different purposes and often complement each other; where one has its weaknesses, the other one has its strengths.

An organization could probably also benefit from letting employees choose their own tools for ad hoc content-centric collaboration and communication. At the same time, it would probably benefit from providing an infrastructure and structured and governed processes for producing, managing and delivering business-critical content assets.

It just requires a delicate hand to do the right thing with the right content.

Tuesday, October 16, 2007

Why You Need a Concept Model for Integration

"A human being is part of a whole, called by us the 'Universe,' a part limited in time and space. He experiences himself, his thoughts and feelings, as something separated from the rest - a kind of optical delusion of his consciousness. This delusion is a kind of prison for us, restricting us to our personal desires and to affection for a few persons nearest us. Our task must be to free ourselves from this prison by widening our circles of compassion to embrace all living creatures and the whole of nature in its beauty." - Albert Einstein

An Enterprise Content Architecture (ECA) essentially consists of content (elements) and metadata (attributes and relations). By applying the proper types of metadata to describe and organize the content within an enterprise, the ECA makes sure that it can be managed and delivered as needed. So far so good. But, the main challenge when trying to establish an ECA and integrate content from various content sources is to overcome two great barriers related to the metadata that surrounds the content:

  1. The first barrier has to do with the structure of the metadata. If the metadata in one content source is different in structure from the corresponding metadata in another content source, we must make sure that they get the same structure.
  2. The second (and even greater) barrier has to do with the semantics – the meaning – of the metadata. If the metadata in one content source does not mean the same as the corresponding metadata in another content source, then we have a problem that we need to resolve. If we are not aware of sematic differences in metadata between two content sources that are to be integrated, then we might get in serious trouble.

To develop an ECA is obviously a challenging - but not impossible - task given that most enterprises have lots of content sources where both the structure and semantics of the metadata have been defined in isolation from how they have been defined in other content sources. This phenomenon iscommonly refered to as the development of “content silos” or “content islands” and it is a result of IT systems being developed to support only specific functions, parts of processes or – at best – entire processes within an enterprise. That is, without an enterprise perspective where all processes and IT systems are viewed as being part of a whole.

To be able to merge different content architectures, there is really no other way than to go back and first (re-)define the basic concepts used in the enterprise. Only when you have established a (agreed upon) concept model on enterprise level you can start to map the content models in different content sources with eachother. Here is a basic approach to establish the enterprise concept model:

  1. Make sure you have commitment from top management and then create a team with represenatives from all “content islands” (that is, departments and/or processes)
  2. Make an inventory of existing content and which content that is needed but does not exist
  3. Identify which content is valuable to the enterprise and therefore should be classified (and managed) as assets
  4. Work out an enterprise concept model in modeling workshops

The enterprice concept model can then guide the creation of enterprise metadata standards, enterprise taxonomy development and (structural and semantic) harmonization of metadata in different content sources thoughout the enterprise.

Friday, October 12, 2007

The Role of an Enterprise Content Architecture

The role of an Enterprise Content Architecture (ECA) is to structure, describe, organize and harmonize content resources within an enterprise so that they can be managed and delivered as content products to end users according to business needs and requirements.

One of the main drivers for establishing an ECA is to reduce the costs for producing and managing content. Simply put, an ECA will bring valuable content resources to the surface so that they can be accessed and found. The reverse scenario is that you don’t find the content resources you are looking for and need to re-produce them. Furthermore, if a content product needs to be delivered in different ways – such as via different channels that require different format and structure for the content product - the ECA makes sure that the content resources from which the content product is built can be reused.

What is even more important than reducing costs is that the ECA provides the foundation that enables users (humans aswell as machines) to exchange and share information and knowledge. Is does so by semantically integrating content resources of different formats, structure and types which are otherwise living on their own islands (or kept in silos) somewhere in the enterprise. This is also where the ECA meets the Enterprise Information Architecture (EIA).

While the ECA is primarily focused on supporting the effiency of enterprise content management processes, the EIA is primarily focused on supporting the information needs within the enterprise - to provide the right information at the right time to the right user. Is does so by defining, organizing and describing content products in ways that it supports how different users in different usage contexts look for information and how they want / need the information delivered to them. It goes without saying that need to have both an ECA and an EIA and that they need to harmonize while still being allowed to be different.

An Enterprise Content Architecture semantically organizes content resources that may be of different granularity and be more or less structured. The architecture – relationships between content following certain rules – is created with the use of metadata, such as taxonomies. The ECA also addresses how to structure, describe and store content resources for optimal production, management and delivery of content products to content workers and end users in the business.

In an upcoming post I will look at what kind of questions you need to address when defining and designing an Enterprise Content Architecture.

Tuesday, October 9, 2007

ECM Illustrated – Where Supply Meets Demand

Hungry for three-letter abbreviations? Here is an attempt to (re)define what ECM, ECA, EIM and EIA stand for and how they relate to each other.

Enterprise Content Management (ECM) is a collection of processes (supported with technologies) for managing any kind of digital content throughout its entire life cycle within the context of an enterprise.

The Enterprise Content Architecture (ECA) semantically organizes the content resources within an enterprise with the aim to support efficient and secure managament of digital content throughout its lifecycle. The ECA provides the structures needed for efficient ECM processes.

Enterprise Information Management (EIM) is a collection of processes for identifying what information the organization needs to function efficiently, and making sure it gets it, i.e. providing the right information to the right user (human or machine) in the right time. To be able to do this, the enterprise need to have efficient ECM processes in place (make sure to clean up at home before you invite any guests).

The Enterprise Information Architecture (EIA) semantically organizes the information resources (content that is intended to inform users) within an enterprise with the aim to support its information needs by providing a structure that connects users (human or machine) with the information they need. The EIA provides the structures needed for efficient EIM processes.

ECM and ECA is working on the supply side (provider) while EIM and EIM is working on the demand side (user).

Monday, October 8, 2007

How much "Enterprise" is there in ECM?

A lot I would argue. But ECM is - sadly - often discussed on a level where it is synonymous with ECM technologies. However, ECM is not a technology or a software product; it is a strategic approach on enterprise level on how to address the content management issues and challenges most enterprises are facing today. The disciplines of Enterprise Architecture and ECM should be a perfect match - in theory. In practice, their relationship is struggling because ECM is much more occupied with bits and zeros than with people and processes.

Here are a few posts more or less related to this subject that I have found interesting:

"Enterprise Architecture and Enterprise Content Management" by Rajiv Dewan:

"In my experience working in the ECM arena, I have seen numerous deployments where the client is focussed on a particular business problem, or maybe is trying to address a particular set of regulatory guidelines/requirements. What seems to be lacking is a true understanding of how a content management solution fits into the Enterprise Architecture ...//.,. My personal view is that most ECM deployments, and this is on the vendors and systems integration/consultants who deploy these solutions, are not really architected to fit into a corporations 'Enterprise Architecture'. Furthermore, the discipline and rigour of EA is not really followed as ECM solutions are developed"

"Enterprise Architecture: ECM and Compliance Oriented Architectures" by James McGovern

"ECM is not an insular domain and should participate in a larger context ...//... Documentum, Alfresco, Nuxeo, Stellent, Filenet, OpenText and others are way too insular and need to start thinking more about how folks outside the ECM domain may use their products."

"The Enterprise Content Management - SOA Divide" by Alan Pelz-Sharpe:

"In the content management world, I sense something of a backlash brewing against SOA (Service Oriented Architecture), but I wonder how real or or even practical this is. With most Fortune 2000 firms already way down the SOA path, there seems to be no turning back. At the enterprise architecture level, there is no Plan B. So the issue for me is not whether SOA is the way forward for ECM, but rather how seriously some of the ECM vendors are embracing it."

"Transparent ECM and SOA" by Laurence Hart:

"This is where my concerns surface. EMC’s Documentum message has been subtly changing. Less focus on application-like modules, more focus on toolsets, integration, methodologies, SOA concepts and the like. It hasn’t just shown in the marketing. Several of the Content Applications have been slow to evolve in the last few years. There have been improvements, but many of those coincided with the unification of the product stack ...//... Here is the Catch-22. We need an ECM platform that can easily be plugged into an Enterprise Architecture. On the other hand, we like having good, solid Content Applications from the same vendor. Oh, there are times we want/need to mix and match, but many organizations want to at least be able to consider the applications provided by the ECM vendor. It also shows an understanding of the problems that the ECM Platform needs to support."

Finally, James Melzer has developed an interesting diagram called "EIA in Context" which he introduces in the post "Enterprise Information Architecture in Context". He explains his view on the relationship between the Enterprise Information Architecture (EIA) and ECM. The EIA defines the structure for content management, but it must first be aligned with the Enterprise Architecture. To quote:

"ECM is a permanent ongoing process to control a never-ending stream of content - to file it, organize it, and deliver it to the people who need it. EIA is the intelligence behind content management. It translates user needs, business goals, policies, and standards into a coherent plan for content management."

How to present an upgrade?

7:57:00 AM Posted by Unknown No comments
When upgrading an off-the-shelf application or service that is configured for a client, rather than code customized, you would expect the supplier to provide a script that is executed to convert all necessary data and configurations. A script like that must of course be executed a couple of times and proper testing done in each iteration by both the supplier and the client.

This is all fine and well, but if the customer also wants to take advantage of new functionality or if new features force the client to make additional configurations, then the upgrade has to be planned more carefully. When upgrading software that is a configured service there is always the element of client and supplier activities and expectations that have to be aligned and met. Still, a project like this is small and well defined which should make it easy to plan and execute.

Considering these facts one might wonder why these projects fail so often and why the client seem surprised every time an upgrade like this fails. In my experience, the villain of the piece is - as usual when something fails - communication. The supplier presents the upgrade as a walk in the park and the client communicates internally about all new fancy functionality that will be available with almost no effort. Nothing could be more wrong - maybe it lies within the human nature to be naive when presented with the possibility to make a process smoother through new or improved features?

Friday, October 5, 2007

I call for e-notifications

1:47:00 PM Posted by Oscar Berg , , No comments

The number of e-mails in my inbox that are just notifications – short and automatically generated messages that inform me about something – has since long surpassed the number of regular e-mails. Most of them I don’t open and read. The information in the subject is usually enough and then I delete them. Some of them I have to open and read, just to view and click on a link to another location.

One of the “truths” in content management is that all content needs to be managed in some way or another. Depending on the purpose and intended (and actual) use of the content, it might need to have a different structure and format and be managed in a different way than other types of content…that is why we define and work with “content types”.

What strikes me every so often when I delete notifications received by e-mail is that I would really like to manage these in a different way than how I manage my other e-mails. For example, I don’t want them to be mixed up with other e-mails. I would like to view and manage them separately. I would also like to have them automatically deleted after some period of time. And, maybe it would be an idea to have all the information in the subject so that I don’t have to bother to read the body of message?

Much of what I ask for I can achieve - after some effort - by configuring an e-mail client such as Outlook. But should I really have to do this? Aren’t more people than me interested in viewing, using and managing notifications in another way than regular e-mails? If so, then not just I would welcome an initiative that defined, specified and enforced a new standard for notifications. Maybe there even is one on the way?

Thursday, October 4, 2007

The Enterprise 2.0-generation and the future

9:13:00 PM Posted by Tommy , , , No comments
What can we expect from the future corporations whose leaders and information workers all grew up in a world where internet already was labelled “2.0”? When I grew up, in the early seventies, e.g. young girls all had diaries with little heart shaped padlocks on. No one was allowed in to their secret thoughts. Today, young girls are publishing their diaries on blogs, open for the entire world to read and reply to. When me and my friends did something really stupid, we tried to keep it to ourselves. Today the film is on Youtube within seconds after the situation. The drive to share and take part of other peoples “business” is enormous.

Now, take this collaborative force into the future corporate world. When we, and every other generation grew up, knowledge was power in the sense that you should keep valuable information to yourself and act on it when the best opportunity came along. Hence, even though the wind is changing slowly, today’s business mostly depends on few people who know a lot. Tomorrow the business will depend on many people who each have specific knowledge. Tomorrow, knowledge is a fresh fruit that should be consumed fast or it will be useless. Knowledge will be power in the sense that you can use it to broaden you network and collaborate with even more communities and so on.

So, what about the future corporations then? Given a continuing technical evolution, we will have the possibility to seek and find relevant knowledge for an existing or upcoming situation within our organisations in a way we never had before. The leaders should be able to get more relevant and fresh information to act upon then ever seen before. The key to this is of course the power of the learning communities, the social operating systems and the networks. The leaders and information workers of tomorrow will have this power built in from kindergarten and they will know of no other way to conduct their business than to cooperate with others, share ideas, keep discussions going and making it all public within the organisation. Business Intelligence will move its focus to tracking and monitoring these communities and seek out the relevant information instead of aggregating and analysing already distorted data from legacy systems, and creating charts that are out of date even before they are compiled. The good part is that as long as the climate for starting and running the communities is healthy, the communities will almost take care of themselves. They will define their own set of rules, the do’s and the dont’s, and they will find the best channels for them to publish themselves within the organisations.

Wednesday, October 3, 2007

The Death and Rise of the Web Portal (and Web Site)

3:10:00 PM Posted by Oscar Berg , No comments
Many web portal and web site initiatives have started out with a vision that the intended users should use the portal or site on a daily basis, encouraging the users to make it to their browser home page. This might have sounded like a good idea a few years ago, but how absurd isn’t that idea today.

I can only look at myself. I don’t use any web portal or web site (other than some news and community sites) on a daily or even frequent basis. Even if I find a web portal to point me to attractive content and services, I tend to forget about it after some time and get reminded about it only when I happen to browse through my bookmarks. If I bookmark it at all in the first place.

No, I rather prefer to collect services and content that I find usable and bring them home – to my own portal (currently IGoogle). I just regret that some of the services I encounter on other web sites are not available as gadgets.

Don’t get me wrong. Web portals will still exist in similar shape as today. The big players like MSN, Yahoo and AOL will be around for quite some time. But, they will also need to grow tentacles and stretch them out to the locations where I and other consumers like to hang around, be it IGoogle, Facebook, Myspace or wherever.

"Don't come to us, we'll come to you" should be the mindset of anyone that is about to develop a web site (or rather online services and content) today. If the user won’t come to your site, you should bring your content and services to the user.

I guess that I am not much different from people in general in my longing for a good video on demand service. With such a service, I would not have to go to the video rental store to rent a movie I didn’t really want to see in the first place (all the copies of the one I wanted to see was already rented) and then worry about returning the movie in time before I get fined for returning it late. With video on demand, I could sit in my sofa and browse through the movie assortment on the TV with the remove, pick a movie I want to see and see it whenever I want to see it, not wondering if there is still a copy left of the movie that I want to see, or worrying about not returning the movie in time to the video rental store. And since no physical copies would need to be produced and I would pay myself for the distribution of the movie, I should have to pay less for watching a movie (that's what I expect, anyway).

Web 1.0 was about companies creating video rental stores on the web, but without the videos or any other rich content. Instead, what they offered to us was free content and they were happy as long as we paid them a visit once in a while. Web 2.0 is about enabling us to create our own stores, sharing and discussing our favorite movies with others and even creating and sharing our own movies. And bringing the content we like to consume home, on our own conditions.

Monday, October 1, 2007

The Value of Architecture

The value of Enterprise Architecture is zero, if you have an enterprise that exists in a complete static environment, without any need for improvement. The value of architecture is also minimal if the size of your business is small. If you have one customer, one product and one employee is it rather simple to adapt to changes in your environment. With more customers, more products and larger organisation, changes to your organisation are more complex.

First of all, Enterprise Architecture is a vehicle for risk mitigation. Projects fail, and the larger the project, the less the chance that it succeeds. Large programs are even worse. Why is it so?

Standish Group make annual surveys of project results and their findings are not very impressive. Worst of all, there have been no major improvements during the last twenty years. If we look at the reason behind failures, we can identify two major factors behind the figures that count for nearly 90% of the reasons. They are the solution as such and how the project is carried out. Lack of proper project and program management does count for approximately 50% of the failures. The next 40% of failures are due to the lack of architecture. Finally 10% are classified as others, i.e. Murphy.

The other finding is that small projects have a near fifty per-cent risk to fail. Large program does only succeed in 2% of the cases if we look at the statistics. Larger program add complexity due to mutual dependencies between projects. The dependencies exist both between different applications and between processes and people. More applications and larger organisation add complexity to the transformation. Not to forget the strong relationship between the organisation, processes, information and applications. If we don’t handle this relationship will we have a huge gap between business units and IT organisation.

Enterprise architecture is how to describe the situation today, how it will look tomorrow and how we will get there in a controlled way.

If we have a more positive attitude, Enterprise Architecture helps the organisation to improve how they work and add value to their customers. Improved processes and IT-systems that simplify manual work need a strong foundation.

Enabling new business, as information, communication or entertainment services, to the enterprise has a big impact on requirements on the solutions, thus also on the architecture. Collaboration with external parties is another example that call for flexible solutions.

You will have a strong business case for Enterprise Architecture if your organisation stands before a major transformation, due to changes in the environment where the organisation act.

A last word, in a perfect world Enterprise Architecture would be the silver bullet. But in reality, we must handle a number of shortcomings. These are to be described in the next articles.

EA Soft Power Project Reviews (coach, don’t kill)

2:55:00 PM Posted by Henrik Gustafsson No comments

Enterprise Architecture made practical seems to be a topic that currently attracts a lot of attention. In a former post I tried to summarize some guidelines on how to approach Enterprise Architecture (see Practical Enterprise Architecture ). The key purpose of the post was to argue for a more agile approach that is better adapted to the stakeholders' needs and capabilities.

In this post I will describe some tactics concerning Enterprise Architecture and project reviews. Why bother reviewing projects from an Enterprise Architecture perspective? Below are a few possible reasons:

  • A review may result in a more balanced basis for project decisions
  • A review may clarify the alignment between business goals and supporting IT
  • A review may identify synergies and explain different solution alternatives
  • A review may engage competence that the project might have disregarded
  • A review may discover risks that require mitigation
  • A review may reveal aspects of the solution that are not obvious for the project members, e.g. re-use, integration and security

A review can be executed in different ways depending on the size and complexity of the project at hand. Generally, project reviews are performed in a very formal style, when the project is well under way, and the Enterprise Architect or EA team often takes the role of a (bad-guy) police. But is this always necessary?

An alternative approach might be to think about the review as a learning experience for the participants where the Enterprise Architect takes the role of a coach. The style of the review is preferably less formal. The Enterprise Architect identifies issues, leads a constructive dialogue and supports the project by suggesting different architectural improvements. These improvements are for the project to address and resolve.

This type of soft power project reviews should preferably start in the early project phases. This ensures that the project is doing the reasonable right things in the reasonably right way to minimize project risks as early as possible and to avoid the high costs of late project changes.

So, what kind of questions might the Enterprise Architect or EA team use as a foundation for a constructive dialogue with project representatives during an initial project phase? Below are some examples of statements that might elucidate many common project and architecture issues:

  1. The suggested solution is documented and outlined in a comprehensible and concise way
  2. The suggested solution is linked to significant and measurable business drivers, scenarios and services
  3. The suggested solution clearly presents relationships to internal and external actors and stakeholders
  4. The suggested solution illustrates key services and components as well as vital interfaces and interactions
  5. The suggested solution answers to critical non-functional requirements and service levels
  6. The suggested solution is compared to different solution alternatives and emerging IT trends
  7. The suggested solution is related to its life cycle and to possible changes of the users and their usage
  8. The suggested solution shows dependencies to existing IT plans and project portfolios
  9. The suggested solution adheres to enterprise strategies for IT competence and sourcing
  10. The suggested solution follows the established principles for Enterprise Architecture

The above statements may seem simple, but my experience is that most IT projects can not answer to all of them. A project does not need to have detailed responses to the statements during an initial phase. The point is to make sure the project members have started to think about them. Detailed explanations of how the project will solve them will then come naturally during forthcoming phases and reviews.