Evolution – Content and Portal Platforms
As organizations determine what technologies will be part of their technical enablement roadmap, Gartner’s Generation 7 Portals – Unifying the User Experience report, highlights considerations given platform vendor’s move toward consolidation of Enterprise 2.0 functionality on a single platform. Gartner points of that “Whatever their features, organizations much regard portals as a means toward business ends, rather than ends in themselves. Organizations should define the role of the portal infrastructure relative to investments in converging technologies, such as Web content management, social networking, analytics and enterprise mashups.”

Given this roadmap the Enterprise 2.0 Interactivity Spectrum provides a visual guide to how certain business requirements are met by various technologies and for a particular item of business functionality, which platform it commonly resides on.

Figure 1.0 – Enterprise 2.0 Interactivity Spectrum

The Enterprise 2.0 Interactivity Spectrum (Figure 1.0) pictured above examines a series of common functions provided by enterprise platforms, sorting them by the level of active user interaction expected with each one (mouse clicks / points of interaction) and the level of complexity to deliver a solution for the given function (deployment / development time).  Functionality that ranks more on the side of content platform creation and management is marked in light blue, while traditional portal technology is denoted by dark blue markings.  Generalizations were made around each portion of functionality as described below.

Mapping Common Functional Requirements
Based on the following 12 areas of general enterprise 2.0 platform usage it is possible to draw some assumptions and make generalizations as to where these technologies fall within the spectrum. For each of these areas a certain amount of interactivity and complexity of development and deployment are considered within the map. More interactive technologies or technologies that rely on application integration can best be server by content centric platforms, most business user management centric, content production needs can best be served by content centric platforms. Ultimately, the solutions produced by an organization will require a blend of these technologies to be successful, today and beyond.

1. Intranet / Extranet User Accounts – ability to allow users to have an authentication session to the site
2. Static Content – traditional web page content consisting of text and images
3. Discussions / Blogs / Wikis – collaborative technologies that allow multiple authors to interact around a particular area of subject-matter
4. Retention Management – technical capability to ensure complete management of unstructured information’s lifecyle
5. Document Management – online document management capabilities that support access and versioning of documents
6. Social Networking – LinkedIn style networking ability focused on communication across an organization
7. Search / Tagging – social technologies that enable users to locate information stored in various repositories in the enterprise
8. Business Process Management – not within a content or portal platform, but an essential part of many users daily operations. Platforms need some capability to surface process related information.
9. Personalized Content – based on user information, explicit or implicit, the platform must be able to respond to and deliver targeted content to end users.
10. Composite Applications – given the breadth of business platforms that organizations have deployed and support (CRM, ERP, etc) it is important to consider a platform’s capability to deliver applications from disparate systems in a single interface.
11. Rich Media – B2B and B2C online systems ability to serve rich media to clients.
12. Business Intelligence – ability to support highly interactive visualizations that allow users to adjust attributes and views of those visualizations

Positioned for Longterm Success
Thinking about platform investment through the lens of the spectrum allows organizations to select optimal technologies to support their current and future business operations. New needs will emerge over time and platforms will continue to converge to make choosing a system or systems to support the business easier and more efficiently. Until then, the Enterprise 2.0 Interactivity Spectrum will provide a state-of-art guide to today’s options.

Optimal delivery of content can be achieved through a variety of methods, but it is generally a blend of security and filtering via meta data that can drive the most return with the least amount of upfront effort and ongoing upkeep. In a portal environment various platform components have their strong suits and by combining the capabilities of enterprise portal and content platforms much of the groundwork for personalization can be achieved in a configuration-based manner.

In our discussion we will cover terminology and concepts, example scenarios and technical implementation strategies to help showcase how personalization of content can be achieved within a portal.

Foundation

To lay a foundation for our examination, the following concepts and terminology will help us to convey how various layers of technology interact to ultimately provide personalization to end users.

Security and Filtered Delivery
It is important to understand what content is sensitive and needs true security, opposed to simply targeted, filtered delivery. There is often times some confusion that in order for content to be delivered in a personalized manner it needs to have certain security applied to it. Often times it is more the case that they a variety of content is actually accessible to a broad audience, but only portions of it make sense given the context of a particular group of users. Essentially this means that some of the personalization will be delivered implicitly (filtering based on metadata) and or filtered explicitly (based on security settings applied to the materials to be evaluated for delivery).

Coarse and Fine Grained Security
In traditional portal development there has always been a discussion of where and how security should be applied throughout a solution. To help visualize the strategy, security has been placed into two camps – coarse grained and fine grained. Coarse-grained security secures large portions of applications at a page or collection of related functionality level. Fine-grained security dictates what buttons can be seen by the end user based on their role and security groups within those applications. Fine-grained security is ideally powered by a entitlement server technology that centralizes and simplifies access to the management of this detail. Fine grained security can also be used to describe row level visibility within applications, which is one of the finest levels of granularity possible. For the purposes of this discussion we will be focusing on security just above the row level and higher, starting with individual content items and working our way to large sections of content and application functionality. Using the terms fine-grained and coarse-grained help to drastically simplify discussions around security and set the stage for discussing personalization of content.

Pages, Portlets and Rows
Taking the above concept and refining it, we can turn the above information toward our challenges around personalization. It is no different from the challenge of implementing a traditional security model, however unlike content personalization, fine-grained application security is a must and has to be addressed before applications are released to an audience, instead of being an added value to an existing system. For the purposes of the personalization that we are discussing above, it turns out that we end up generally concerned with page, portlet and row level considerations to implement an effective personalization model. The former two are considered coarse grained, the later fine grained.

Example Scenarios

For the best return on efforts to setup personalization it is critical to catalog the information and applications that we wish to deliver to end users. For each item provide a description, note the intended audience and the level of security needed for the item, identifying if it should be accessible only to a particular group of users or a specific user. The line items in the catalog allow the portal and content teams to understand if Coarse (Site, Page, Portlet) or Fine (User) grained approaches are needed for the various areas of content. A visual chart later in this article will further detail Coarse and Fine grained technical implementation approaches in relation to portal and content technologies. Please see the following examples that highlight this cataloging method (please note that all company names are fictional)

A. Bits and Bytes Software, LLC Sales Team

Business Need
In an effort to increase sales effectiveness, B&B Software would like to provide a collection of documents entitled Northeast Sales Enablement Materials to be will be delivered within their corporate intranet that are geared toward a sales team within a specific geography. Unlike a company salary report, this sales collateral does not need to be secured, but we will want to make certain that it is promoted directly to the intended audience. This will allow members of the Northeast sales team to quickly access this collateral directly within the context their portal experience in a regional sales dashboard, without having to browse or search for it.

Implementation Solution
The Northeast Sales Enablement Materials should have meta data applied to them or inherited from a parent folder that they may reside in that indicates the geography that they are intended for. In the example above the content can be delivered via a portlet(s) that queues off of a preference set at the regional dashboard level, noting the region that is active. This indicator could be the region that matches meta data on the collateral or a start node id for a folder that contains that region’s specific content. It would also be possible to use profile information from a sales user’s profile to pass to the display portlet, alerting it to the relevant region. To provide the highest level of flexibility the sales collateral should be stored in a content management system within regional folders, that roll up to a parent folder that holds all sales collateral. This will allow an aggregate view of the content to be easily displayed if needed.

B. Our People’s Genome, Inc Research Directors

Business Need
A team of research directors at a pharmaceutical organization need to collaborate on certain items that detail drug development road maps. This content, unlike the above, does need explicit security, in addition to being available in a personalized manner within the context of the director’s portal experiences. In this case both meta data and security can be applied to this content, both allowing it to be delivered to the correct audience. In addition to the roadmap materials the portal will provide more implicit delivery of personalized content, showing news that is related to key terms identified within the roadmap documents. Unlike the actual development road maps, this is public information, but highly relevant to assisting in development and provided to help the directors stay up-to-date with all relevant information.

Implementation Solution
The drug development documents will be stored in a document management system and will have explicit security applied to them, letting only research directors access them. Within the collaborative space in the portal a portlet will present items for collaboration based on the node in which the documents reside in the document management system. The user credentials from the portal will be passed to this portlet that surfaces the documents, to ensure that only documents a user has access to are displayed. The listing of documents will also return meta data about each item. This meta data can be broadcast to another portlet on the page (via WSRP2 or JSR 286) which will display related drug development news based on the meta data terms from the documents.

C. Yummy Foods, Inc HQ to Franchise Communication

Business Need
Yummy Foods has seen excellent year over year growth of their organization through its franchises, but has begun to struggle with providing relevant content to enable it’s franchises to continue to grow sales in their respective locations. In order to solve this headquarters has decided to provide all of their franchisees with various marketing, sales and performance information through an portal intranet solution. It is important to note that employees of a store also have some access to this portal. To reduce the burden on the store owners, headquarters has decided to provide standard benefit information and various employee forms in the portal as well. Sales materials for the store owners are designed to be deployed at a national level, but marketing plans are designed for particular geographies. The marketing and sales materials should only be accessible by store owners. The marketing collateral requires targeted delivered to the proper regions, so as not to confuse the franchises and have them follow incorrect plans, although they do have the ability browse to see what other regions are doing. The performance information needs to also be secured and will be delivered to the franchisees through reports that are only for a particular store. In order to motivate franchisees to perform at a higher level, general financial information is also posted that showcases the highest performing stores within the organization. Only franchisees should have visibility into to this performance information.

Implementation Solution
In order to service the franchisees and the employees the portal is logically divided into 2 sections, one for employees, another for owners. The content management system supporting the portal is also divided into two sections in a similar fashion. Within the employee section benefit materials are stored with open access, as all users can browse, search for and open this content (please note that security could be placed on these items if the materials varied by country and the franchise organization operated globally). The remainder of the materials above are all delivered to franchisees via a dashboard page within the portal. Based on profile data for a franchisee a portlet within the dashboard will display the relevant marketing materials. This portlet takes the profile information about the franchisees location and executes a search query, combining the geography with a node ID that indicates the search should focus on the marketing materials area. The sales materials are delivered in a similar fashion, but pass a user’s identity into the search, opposed to just a geography. This will allow the search to respect the security of a franchisee and ensure that employees cannot access the content. Top Franchisee Performance information will be delivered in the same manner. Finally, the Franchisee Individual Performance is retrieved in a similar fashion, but each performance document in the content system will be secured on a per franchisee basis and will be displayed only to a single user.

Technical Implementation of “Personalization” for Portal Content

The following chart outlines various levers to drive content personalization within a portal. Note the Coarse Enablers and Fine Enablers illustrate where potential attributes that can impact the granularity of personalization reside within the stack. Each layer of the stack can influence the one below, with the exception of the directory service layer, which should ideally be consumed by each layer to form a consistent security model throughout the stack. If this is not possible, various parameters, preferences and metadata can be sent to the content integration provider (portlet code) to allow it to still provide content based on what a complete security integration would actually provide.

click here to view a full size chart

Generic Portlet Types that Return Personalized Content
The following samples outline approaches displaying a listing of content from a content repository within a portlet for a particular audience or specific user. For most use cases, a single, generic portlet can be used to return the appropriate items that can leverage the points within the diagram above, exposed as parameters to be consumed by the portlet. The parameters can be bound to a starting node in the content system (starting folder) and or used along with a query against the system to return documents within particular meta data. On top of this the actual user context can be passed back into the content system, which provides the finest level of granularity to the results that are returned to the end users. If correctly written or natively available, a single portlet can be used to fulfill all of these examples and can be deployed many times within a portal instance, configured slightly different each time though preferences to meet a particular use case.

a. Region-based Content – Returns a listing of items from the repository based on what high level navigation area a user is in queuing off of an attribute of the particular portal area. This area would generally be a functional section of the business like sales, marketing, research, etc.
b. Region-based Content 2 – Portlet similar to that above that queues based on meta data associated at a page level within a business are to which it is deployed within and executes a query against the content repository to pull back related documents.
c. User-based Content – Portlet that acts as a generic delivery vehicle based on profile attributes tied to a user account that are passed into it .
d. User-based Content 2 – Secure via explicit user group security at the portlet level with the parameters pre-configured for the actual portlet that is delivering dynamic information that is based on a pre-defined query for that user group. As an example, the preference could contain an ID that indicates a node in the content system from which to display a listing of content items from.

Taking Personalization to the Next Level
With all of the above being said, personalization can be taken a step further with some innovative content delivery solutions that have the ability to weigh what content to display to end users based on their interactions with the systems, as well as other data available about the user. This technology is very similar to that of Amazon.com and can be used to power a series of decisions for content delivery that are driven by behavior, making a user more likely to find information that is specifically relevant to their needs. Without having to make a large deviation in business processes for content management or technical architecture, a tool like Oracle Real Time Decisions or similar technology can be injected into the above approaches at a portlet level to further filter what content may be returned to the end user.

Final Thoughts
Personalization of content delivered through a portal does not need to be complex and can often be achieved by leveraging existing attributes from the portal and user, rarely needed to get more involved for most content. The largest impacts of personalization are also generally seen by implementation solutions using coarse grained personalization methods with minimal effort. These small investments can have a large impact on usability within a portal, reducing the amount of time that users spend searching for information and increasing their satisfaction with the portal service.

The Minimalist Approach to Content Governance

Let’s be honest – content governance is far from an exciting topic. BUT the potential of a very small intranet team creating and maintaining a platform that provides an organization with relevant, high value information, helping workers to get their jobs done with greater accuracy and in less time is exciting. It is easy to quickly start producing content, but the challenge is ensuring that the environment is easy to navigate and use on the third week and during the third year.

What can be done to bridge this gap?

Over the next few blog entries let’s take a pragmatic, minimalistic view of a process that can help any team manage a wealth of unstructured information. Based on an earlier article that I wrote around Portal Governance, I am going to focus on using technology as much as possible to support the governance of content with minimal involvement from users. The only certainty about content production is that business users are not fans of maintaining content. Maintenance is overhead and is a long-term investment thats value will possibly not be realized under the current content creator’s watch.

To add context to how we will use technical tools in this process, each post will highlight one section of the content lifecycle process as outlined below

Content Lifecycle Stages
1. Request – Understand the education, purpose, resource and success criteria for content
2. Create – Determine access and workflow for content
3. Manage – Understand ownership and review cycles
4. Retire – Act on thresholds established during the request stage

Within each state we will also elaborate as to
1. Why – why would we entertain doing this?
2. How – the steps that are needed to make it happen
3. Impact – what is the net benefit or loss based on the process

Over the next few weeks we will dive deep into the stages and the minimal amount of time, effort and process within each to make some meaningful gains in the improvement of user experience and productivity in their search for information. It might be a stretch to say that we can make content governance exciting, but hopefully it can end up being painless and paying dividends.

Request Phase

For each project, regardless of size, it is critical to understand the required ownership, business purpose, prerequisite education / resources needed to execute and success criteria around it. Without doing this, there is no way to get a handle on the content life-cyle, resulting in a mass of orphaned material. This lowers the quality of end user experiences.

The good news is that by using a simple process in this request phase – we will not have to revisit this phase unless something drastic changes in the project. For each of the elements mentioned above in this stage, the why, how (technically focused) and impact are outlined with the intent of providing the most value to a small team.
read the complete Request Phase on Oracle’s Fusion ECM Blog

Create Phase

In this installment of our Minimalist Approach to Content Governance we finally get to the fun part of the content creation process! Once the content requester has addressed the items outlined in the Request Phase it is time to setup and begin the production of content.

For this to be done correctly it is important the the content be assigned appropriate workflow and security information. As in our prior phase, let’s take a look at what can be done to streamline this process – as contributors are focused on getting information to their end users as quickly as possible. This often means that details around how to ensure that the materials are properly managed can be overlooked, but fortunately there are some techniques that leverage our content management system’s native capabilities to automatically take care of some of the details.
read the complete Create Phase on Oracle’s Fusion ECM Blog

Manage Phase

Most people would probably agree that creating content is the enjoyable part of the content life cycle. Management, on the other hand, is generally not. This is why we thankfully have an opportunity to leverage meta data, security and other settings that have been applied or inherited in the prior parts of our governance process. In the interests of keeping this process pragmatic, there is little day to day activity that needs to happen here. Most of the activity that happens post creation will occur in the final “Retire” phase in which content may be archived or removed. The Manage Phase will focus on updating content and the meta data associated with it – specifically around ownership. Often times the largest issues with content ownership occur when a content creator leaves and organization or changes roles within an organization.
read the complete Manage Phase on Oracle’s Fusion ECM Blog

Retire Phase

Good news – the Retire Phase is actually more fun than the Manage Phase. During the Retire Phase our content management team should not have to track down content creators if the Request Phase of this process was completed successfully. The ownership meta data, success criteria and time stamp that was applied to the original content submission will help to manage content at the end of the content life cycle. The Retire Phase will provide the opportunity for us to prune irrelevant content items through archiving or deletion, keeping the content system clear of irrelevant information, streamlining users ability to browse and search for content.
read the complete Retire Phase on Oracle’s Fusion ECM Blog

All organizations support a variety of systems that can create and contain unstructured information like documents, images, video, audio and other materials.  These items are  used by business users to support functions like sales, marketing, research, or collaboration between various parties.  As a business grows and changes over time it becomes very costly to house, maintain and control each of the dispirit repositories and access their underlying information, as each repository generally provides its own means of control and access.  At one point in time, these solutions were deemed effective for their specific purpose, but ultimately lacked some ability to audit, regulate, version, secure and govern the content that they housed.  Often times these systems were also closed from developer access and their information was only available from a specific application.

There are many benefits of a scalable content management platform like Oracle’s Universal Content Management (UCM), but adoption challenges remain, as people inevitably ask about migration strategies to new tools.  To help reduce the time, cost and effort of migration the following strategy has been highly effective – view existing content items as being an Artifact or a Perishable Content item as outlined below.

Artifact – an artifact is something that must persist within an organization as a point of reference, will not change from its current format and is required or mandated to persist for an extend time.  This might be the 401k retirement guidelines for a given tax year, an annual company report, sales performance figures from a particular year, technical manuals for a specific product version, etc. are good examples of such materials and will at some point be called upon for reference by an end user.

Perishable Content – perishable content rarely needs to persist within an organization, but due to loose governance policies and the speed  at which user-generated content proliferates it is not uncommon for it to live on for years.  Legacy departmental news, sales strategies for products that no longer exist, office lunch menus, materials from defunct business units, materials used for single-point in time collaboration and other items that will never again be accessed by users are all examples of Perishable Content.  At first glance these materials are harmless, but end up cluttering your enterprise with irrelevant information, increasing the time that it takes users to attempt to browse and search for information needed for their tasks.

Strategies
Categorizing content as an Artifact or Perishable content makes it much easier to approach the process of “migration”.  Based on the categorizations we are now left with the following options:

1. Artifact only Migration
Introduce a centralized system like UCM and migrate only Artifacts into the new platform to allow them to be found by users through search and browsing activities.  Leave all Perishable content in its current repositories, to be decommissioned at a future date.

Production of all future Perishable materials should move to the new platform,  but should now be subject to life-cycle guidelines based on the nature of the content that outline how long the content will exist before archival or destruction.  The decommissioned content should still remain available after the cutoff for a specified amount of time, to IT staff or through a self service read-only search.

2. Artifact and Limited Perishable Content Migration
This strategy is more common than the one above.  Move all artifacts into the new content management system, but critically evaluate certain business processes that produce Perishable Content to understand if their production needs to be moved to the central system.  Often times Perishable content is tied with key processes for critical day-to-day business functions that need to be immediately moved to the new platform or continue to reside on the legacy platform with an end date for use defined.  An example of this may be project collaboration documents.

Bringing a new content management system into a business requires not only a technical effort, but also an educational effort around the content creation and management processes that will run on the new platform.  When reviewing the various content types and processes in legacy systems it is important to carefully qualify what will be moved over to the new platform vs discontinued or in some cases persisted in the legacy system.

Results of Migration
By classifying content as Artifacts or Perishable it is possible to pragmatically approach content migration onto a single, enterprise caliber platform in a time and cost efficient manner.  Migrations do not need to be wholesale for value to be gained and with some basic analysis it is possible to quickly understand how various pieces of legacy content should be dealt with.  Post migration IT teams should have a much lower cost of ownership over content within their organization, as now a single, centralized location will exist that can enforce content life-cycle guidelines and allow open access to the materials from a variety of other enterprise systems.

The above mission statements are ultimately empty and provide no guidance or control over the execution of tasks that will take place to fulfil them.

In his book Winning, Jack Welch emphasizes the need to take a pragmatic, no-nonsense approach to mission statement development if any real value is to be gained by it.  Mr Welch states that “Too often, these exercises end with a set of generic platitudes that do nothing but leave employees directionless or cynical. Who doesn’t know of a mission statement that reads something like, “XYZ Company values quality and service,” or, “Such-and-Such Company is customer-driven.” … Give me a break—every decent company espouses these things!”

To make the most out of a project charter’s mission statement it must be meaningful enough to provide business justification, focus the project execution and provide a high level metric to objectify project results.  If developed correctly, a mission statement will act as an excellent compass by which to deliver a successful project.  This is done by clearly defining

As I have written many times on Infotechaligned – the only thing that matters is the ultimate business value that an application is delivering. The most value can be gained from even the most mundane technical solution.

How does one define a great technical solution?  The best technical solutions solve a business problem with the least amount of technical effort.  This includes effort from a full lifecycle standpoint – design, development, implementation, education, operation, maintenance and decommissioning of the solution.  A few years ago I worked with a company that demonstrated this point so clearly that I had to highlight it in this post.

This particular organization lends money to low income families at below market rates to aid them in home purchases.  For a few years they had been using portal technology that from a development standpoint was focused on business users.  This technology required little programming to allow them to further develop their extranet and intranet environments that connected their customers on the lending and purchasing sides of their business.

A need arose within the organization to provide executives with a summary of call activity from their sales team to judge the effectiveness of various calling campaigns.

The IT team spent time deliberating over what course of action to take to solve the business problem.  It was decided that the executives could be best served via a dashboard that would roll up various pieces of performance data around these calls made by the sales team and surface the information via their existing intranet.

The following two options were arrived at assuming that the requirements gathering for the solution was already complete, irrespective of the technical solution

Solution 1

Extend their base CRM system to support tracking this data and develop an integration to aggregate and present the data.  This solution would require the following development efforts

1. Extend the data model of the base system to account for the new reporting needs
2. Develop a presentation layer to gather the relevant information for the business users based on this data model
3. Create a presentation layer to allow executives to view and sort the information
4. Integrate the presentation layer into their intranet
5. Complete a quality assurance cycle on the solution and resolve any issues found with the technological implementation

Solution 2

Use an out of the box – MS Access like – portal component that is already available to capture and present the information.  This solution would require the following development effort

1. Configure the data model and forms relevant for the data collection around the business needs
2. Configure the presentation layer for the end users to expose the required reports

The above comparison might be deemed biased, but it is important to note that in the 2nd solution data would now be entered into two distinct systems by the sales team and the organization will not have complete control over the presentation format beyond a series of basic, caned reports.

After lengthy deliberation the IT team was strongly in favor of using the first solution due to it giving them full control and confining all sales team activity to the CRM system, but estimated the time to completion at around four months of effort.  This effort would detract from having their developers work on core offerings within their extranet to drive business leads to the sales team.  The development and QA time, not to mention possible adjustments that may be needed after an upgrade of the underlying system also added to the overall “cost” of the integration.

The first solution would require around 8 hours of effort to configure and 10 minutes from the sales team each week to summarize their call activity, which would be required regardless of the technical solution selected.  It would be created on top of an out-of-the-box technology and require almost no quality assurance testing, but require the sales team to end their day outside of their CRM system and leverage the intranet for summation of their calls.

In a perfect world we would have the deep integration of the first solution, married with the ease of development within the second solution. Unfortunately that was not feasible and the business team was requesting a solution as soon as possible from IT.

Ultimately the IT team went with the second option.  If more complex needs arose that the configuration based solution could not meet they would have to revisit the solution, but for now they were able to meet 100% of the business needs with this stop-gap effort in a very short time span.  Given the limited effort and accuracy in addressing the problem, this had tremendous positive impact with the business.

This example of success is perhaps one of the most powerful, pragmatic solutions that I have come across in my enterprise software work.  This is an extreme example, but hopefully there might be a space within your organization that allows you to provide this same level of success with minimal effort.  Using simple, configuration-based approaches to development whenever possible is an outstanding way to provide value.  They may at first seem too lightweight and due to their technical ease may be overlooked at first pass by a development staff, but never count them out for their ability to provide a big win for your business teams.

Once within a discussion it is even more important to constrain the volume of each participant if the discussion is going to be effective.  There should be one message and all supporting materials shoudl directly support the main message.

For the purposes of relating the dinner party group discussion to an intranet page, we can continue our example from the “arrival” scenario described above and think of this as a detail page describing expense policies for automobile rentals that was accessed from a page outlining all expenses policies.

The pyramid above illustrates the increased focus that is needed to make a detail type of page effective for the guests.  The supporting information on the page only supports the main point.  Any of the other material generally does not have more detail than a nagivational link to another section of the site.

I hope that the above explanation can help people to convey the importance of contrast in their designs in order to make a guest’s experience as efficient as possible.  For information around prioritizing, organizing content and messaging on a page take a look at Intranet User Experience Design.

The pain generally becomes apparent when trying to figure out why old content exists within the intranet or how to restructure content after reorganization. I have had the luxury of being part of many corporate intranet developments and privy to the management teams and activities behind them. Based on what I have seen there are a few quick and easy gems that help to reduce the management overhead of running an intranet. Please see below for the series of tips that collectively can free the time of an IT staff to focus on more pressing needs.

Tip #1
Content Owner – always include a link to contact information of the content owner, their manager and department on the pages that they have created.

Why?
Inevitably your intranet will grow over the course of many years. Over this period of time employees will leave, change departments, etc. It is guaranteed that people will periodically wonder why certain content may be out of date or if it still belongs within the intranet. You now have a simple fix.

Tip #2
Empowerment – an IT department is not allowed to post content for the business.

Why?
Due to the maturity of content management systems it is counterproductive to have IT posting business content. Their time can be much better spent looking at ways to automate process for the business or reduce the amount of time it takes to access and use certain systems. Learn more about how business and IT can collaborate to maximize value.

Tip #3
Peer Education – if someone wants to post content on the intranet they are required to take a quick course on the basics of how it is done. Once a member of a department or project has been taught – they are now responsible for empowering others in the group who wish to use the technology.

Why?
Just like tip #2 an intranet is going to be most successful when the content maintainers are empowered to manage their own content. By supporting bad habits and shortcutting the proper process the reliance on IT for these tasks will be reinforced. Learn more about Maximizing Portal ROI – Education, Production Capacity and Stewardship Delegation.

Tip #4
Search – add metadata to content to provide clean search results.

Why?
Tending to Metadata might sound impractical and create a high level of overhead for content contributors – but it is an essential part of making sure searching for data within the intranet is painless. This is especially true when then same keywords can produce a result set with irrelevant information. A good example might be people that work with products and or services that have various version numbers. Chances are that when you run a search the result set will contain very old data, in addition to the new data that you are looking for. This can be frustrating as we potentially can only search on relevancy or date, not both at once so by adding some simple metadata to indicate the version of the product or service that we are searching for. Learn more about Portal Governance.

Tip #5
Feedback – make it easy for users to send their feedback to content owners (see Tip 1 above)

Why?
If there is an issue with the content or a request about it, the owner can be quickly reached. This saves time for people trying to connect with various parts of their organization needed to complete their job and generally enhances the quality of the content within the intranet on the basis of feedback.

Tip #6
Insight – if your intranet platform has available search logs check them periodically

Why?
This provides a wealth of information about what is important to your users and indicates how the intranet and business teams might be able to better help them. If people are searching for various topics that do not have corresponding content within the intranet, it can potentially increase the value of the intranet for the end users by including content around what they were searching for, but could not find.

I hope that this list has been helpful and uncovered one of more items that have not been considered for your intranet deployment. Do you have any tips that you would like to share? Please feel free to drop me a line with your thoughts.

Organizations are beginning to recognize the value of deploying consumer Web tools to obtain basic benefits like internal knowledge sharing. This being said, they often overlook deeper benefits that the elements, and, more importantly, their methodologies of collaborative contribution can provide. Due to their ease of use, organizations can leverage these tools to allow for natural participation within their traditional application-development processes, allowing both developers and business analysts to jointly contribute to solution development.

Natural participation is an agile, cost-effective, and logical participation model made possible by portal or portal-like frameworks that let business analysts design processes, content, structure, and other elements of a solution in parallel and in participation with a traditional software development team. A tremendous amount of business value can be gained from the speed, ownership, and maintenance in a solution-delivery model that stresses participation of the business units involved in creating the overall solution, while not relying exclusively on a development team to carry their vision to completion. Natural participation can be thought of as “Agile Development Plus” to further accelerate overall solution delivery.

As an example of how natural participation could be applied to a non-technical task, imagine multiple participants actively assisting in creating a painting on canvas. Based on their strengths, the participants would contribute their various degrees of skill and help where it made sense. Perhaps a particular team would focus on painting trees from a template to free up the highly skilled artists to work on the complex and unique details of the people in the painting. When the work was done, viewers would appreciate a single painting for its overall qualities, not knowing that multiple authors with various competencies were involved.

Whether developing an online mortgage application or a business-to-consumer Web site, this participatory method is made possible and effective by leveraging Web 2.0 principles of contribution.

The Frozen, Monolithic Past

Applications have historically been deployed by IT teams based on the waterfall development model, which results in monolithic, often cumbersome solutions. All elements of an application have been controlled by the development team including textual content, taxonomies, site structure, surveys, dashboards, and other elements. Although many great solutions have been built this way, unfortunately it has cast the development team as the bottleneck.

Here are some drawbacks of the traditional development model:

• The team is slow to react to business needs.
• The development team becomes the bottleneck for initiatives.
• There is more code to maintain.
• There is more code to test.
• Regression testing is needed for application updates.

It we take the monolithic model to its extreme, it could take weeks to adjust the destination of a simple hyperlink within a Web-based application. If an item of content needs to be changed or the structure of the site requires adjustment, the development team is always tasked with this effort, reducing available resources for other projects. A series of regression tests may also be needed to ensure that the application is able to continue functioning without being affected by the recent change.

Once again, many outstanding solutions have been developed this way, but we can all agree that this process is not without significant drawbacks.

Passing the Baton

Members of application development teams take great pride in delivering solutions to the business, and rightfully so. They have worked hard to gain thorough insights into complex systems that they weave together to meet the needs of the business. This can also make it difficult to relinquish control over portions of applications and move to a more iterative, natural participation model of development.

When it comes to control, it is only logical that concerns over development efforts running wild without the steady hand of IT would abound as business analysts begin to have further levels of participation. To combat this fear, enterprise vendors have been careful to not overlook governance and security controls, establishing approval processes, appropriate access, and auditing possible within their new tools.

Once IT realizes that their efforts are best spent focusing on high-value strategic tasks to drive their own efficiencies and cost reductions, resistance to this change falls away.

The Big Thaw: Natural Participation in Action

A fictional corporation called Blue Walnut Realty (BWR) had a public Web site that allowed customers and business partners to connect with them at www.bluewalnuthomes.com. The Web site had a public-facing section that contained marketing material to help generate sales leads and showcase their services. In addition, the site had two secure areas that allowed home builders and home buyers to access an online application.

The customer application helped potential home buyers keep track of favorite properties that they were interested in purchasing. The secured home builders section of the Web site let builders add and update their property listings within the BWR database so that potential customers could browse and add these property listings to their favorites.

Historically, BWR had used the waterfall development method to support these applications and had released new functionality or adjustments to their Web site on a bi-yearly basis. All development efforts were handled by their development team, which met with business analysts to transform the latest business requirements into solutions.

Over time, BWR had seen their growth slow as smaller, more nimble competitors began to offer similar functionality on their Web sites and more quickly adjust to meet consumer needs.

Recognizing that their Web presence was a crucial element of their overall business strategy and that it would help them grow their business, the BWR CEO and CIO committed to investing in a more flexible Web framework and to researching ways to leapfrog their smaller competitors. To support this new business initiative, BWR also revisited their development processes and began investigating agile development methods. During their investigation, they came across the principle of natural participation in this new framework and decided they would also leverage its methodology.

The results were significant. By adopting a natural participation method of solution development, they quickly found themselves accelerating their initiatives at speeds they hadn’t thought possible. With developers and business analysts collectively contributing in parallel, which was not possible earlier, the same number of resources could now produce much greater results in a shorter time span.

Within a week of moving to the new platform, a new feature was added to the Web site that allowed potential home buyers to start a discussion with BWR staff around potential homes on the same Web page where they stored their favorite listings. This added a much more personal touch to the Web site, and the potential customers were very pleased with the new functionality. The development team invested no effort on this initiative as the business analyst team used native framework tools to create the new interactivity for the prospects.

BWR also wanted to strengthen relationships with the home builders. Immediately after adding the discussion forums, the business analyst team began to weave in targeted marketing materials explaining the benefits of working exclusively through BWR alongside the application that home builders used to add and update their listings. In addition to these materials, the team created specific contact forms to allow the builders to show their interest in specific programs offered in the marketing materials.

A few more weeks down the road and using native portal tools again, the business analyst group set up individually branded logins for all of the major builders to bolster relationships with them. This required no developer assistance or regression testing from the development team as it was native framework functionality. The individually branded logins were something that none of their competitors offered, giving BWR a distinct advantage.

What about the application development staff at BWR? Throughout this entire process, the development team had been freed up to focus on more strategic technology projects. They are now preparing to release a new tool within the site that allows potential home buyers to download their favorite available properties to a GPS device that can easily guide the prospects through a tour of the properties. This is a feature that no competitors have and something that was made possible by using the time not spent updating site content, adding new interactive site elements like the discussion forums, updating site structure, building uniquely branded login areas, or deploying marketing materials for the builders.

How to Implement Natural Participation

Leveraging principles of natural participation requires coordination from a business and organizational standpoint, as well as from a technological standpoint. There is no perfect approach to its implementation, but the overall goal is to obtain benefits from a pragmatic, agile approach to development with multiple parties. Below are some key steps that will help organizations begin to embrace this ideology for projects.

1. Secure executive sponsorship — Change is difficult. Even though many benefits exist from implementing a model of shared participation for solution development, it will take a compelling executive voice to reinforce the new strategy. In the absence of this support, people will gravitate toward the status quo where they are comfortable.
2. Know all facets of your application framework — It is crucial to look for areas within a development framework where non-developers can contribute and manage part of a solution. This frees developers to focus on more crucial initiatives and frees the business from the bottlenecks of waiting on the completion of long release cycles to make minor adjustments to a project.
3. Challenge the current Software Development Life Cycle (SDLC) and release management approach — Too many companies do things “because that is the way we have always done them.” Step back and examine if a traditional model makes sense given the evolution of platforms and their ability to now develop more modular solutions where multiple audiences can manage different segments of a project.
4. Explore delegation and define governance — Just because a development team may no longer code an entire solution does not mean that it has to result in a loss of control over content. Modern development platforms can provide workflow, auditing, and other methods of managing segments of a solution in a secure and controlled manner.
5. Identify obvious candidates for delegation — Content, information structure and layout, high-level security, and workflow are just some elements that business users can manipulate within a platform. The business can focus on these portions of a project without affecting development efforts and offloading a significant amount of work from a development team.
6. Keep all parties informed — The development and business teams should participate in regularly scheduled, brief meetings to inform each other of their project activities at a high level. This will ensure that any change in overall project direction or business requirements will have minimal impact on the work that both parties are doing and how that work is integrated between them.

Conclusion

By leveraging the principles of natural participation, it is possible to thaw enterprise application development, making the most of a portal framework and native tools that enable contribution by non-developers. Each initiative can be evaluated as to whether it makes sense to begin traditional development work for a segment of the solution, or if it is possible to involve members of the business-analyst team to paint that part of the picture. This process leads to greater business agility and allows development teams to focus on higher-value strategic tasks, while business analysts become empowered to “naturally participate” in the overall solution development and increase the business value that IT can offer to its organization.

In this exploration we address the latter of these two scenarios, in which business user empowerment allows knowledge management solutions to quickly be constructed and the barrier to effective knowledge work to drop within an organization. People are hard pressed to deny the “cool” factor of these new tools, but these suites inherently pose some tough, critical questions about their business value. Between the practical application of these technologies, challenges around governance and security, and issues around education and adoption, it is easy to see where an organization has to think long and hard about implementing these tools and ask important questions:

• Where do these tools fit into the enterprise?
• How can we govern the usage of these tools and manage the data generated by these tools?
• How do we leap the user education hurdle?
• How can these tools generate business value, thereby justifying a potential deployment?

Once you are able to address these points and understand what makes sense for your enterprise, you can identify where these product sets can provide value. You’ll be able to see that harnessing these tools makes it possible to accelerate knowledge work through the capture and presentation of information through user-authored spaces. It will also be possible to calculate an objective return on investment by measuring key performance indicators that satisfy the justification for the toolsets. Ultimately, this allows you to unlock value from enterprise knowledge management for your organization, granting you new levels of knowledge sharing and efficiency.

Fitting Into the Enterprise

A medium- to large-scale enterprise has an electronic mail solution along with a host of vertical applications implemented to address core needs like procurement, financials, and other common line-of-business needs. These tools run the gamut in the way they allow users to produce and manage an organization’s data.

Email is the essence of unstructured data and, conversely, vertical applications manage and host rigidly structured data. In organizations where knowledge work is occurring, these tools fail to provide a platform to act as a workspace to facilitate the dynamic, ad hoc collaboration around business challenges.

Although written from a sales and marketing standpoint, Chris Anderson’s book The Long Tail details dormant economic value that goes unaddressed by large systems. Only when a vehicle exists to cost-effectively address niche needs will this value ever be realized. We’re continually presented with projects that have technical solutions falling somewhere between unstructured email and highly structured vertical systems like SAP. Enterprise 2.0 collaboration technologies support the needs in this middle ground that never could have been managed or cost-effectively addressed before.< /p>

This middle ground, or “whitespace,” has traditionally implied custom development effort, and generally it took six to eight months to develop a solution for even the smallest of business problems. When business users need a tool to manage this middle ground, it is not feasible to justify custom development, and the business makes use of the only tools at hand to tackle the problem. These have traditionally been email and other tools that are not well suited to knowledge management work.

User-driven product suites shine under these circumstances and provide a framework for teams to quickly create and manage these situations. When business users are able to identify a need that the traditional application space does not address and quickly satisfy those needs with these toolsets, value is realized because they do not need to engage development resources from the IT arm of the organization; instead, they can respond at near real-time speed. This allows IT to focus on more strategic projects around their core business that do require precious resources, and business users can work efficiently within a managed space in the enterprise.

Governance

With highly dynamic collaborative tools, mitigating fears of misuse is not a trivial matter. Within most organizations, any electronic information outside of email and casual office documents requires some degree of formal regulation.

Often, a battle ensues between business teams and technology management teams as to how best to use the tools. To make the most of the toolsets and to obtain the greatest business value, a reasonable, but not overzealous, level of governance must be placed around them. When we think of governance within a highly dynamic collaborative environment, some basic principles can be followed to smoothly manage the processes, while still allowing business users to create value.

Like a traditional IT initiative, obtaining executive- or departmental management-level sponsorship is crucial to the success of the initiative. Just because the toolsets enable fast solution development does not reduce the need for sponsorship. In addition to the sponsorship, the purpose of the deployment needs to be clearly defined. It is not enough to deploy a project with the toolset just because of the features available within the toolset. Feature-driven projects are destined to fail.

After the solution is in place, it will need to be maintained. This means that a clear owner must be defined for the outputs of the project. This owner will need to obtain any requisite training to support and enhance the solution going forward.

Based on the purpose of the deployment, it is essential to identify what information will be committed to these spaces. Will a space contain information that is sensitive and in need of being secured? Who will have access to modify, edit, or add information to this space? What level of auditing needs to be put into place? Knowing the answers to these questions upfront will allow you to set up the correct access permissions to enforce business policies within the workspace.

Finally, a plan for periodic review of the project’s outputs needs to be defined. This review acts as a checkpoint to make sure that not only technical but also business process rules are being adhered to. The review should also contain procedures and metrics that measure when a space should be discontinued due to nonuse.

Outside of security, at the end of the day, much of the governance with toolsets that pose a low barrier to entry will boil down to business processes. People in organizations need to be responsible for their actions at a business level beyond the technology. This is where a clearly defined plan based on the above elements is crucial if people are to succeed with enterprise 2.0 technologies.

Education

User-driven products that provide expedient gratification with regard to the reduction of daily burdens and processes have exceptionally high levels of adoption. Public examples of such systems underscore this trend, including the social networking site MySpace and blogging tools like Blogger and WordPress; these are definitive examples of tools that self-educated users have quickly adopted and gained value from, without extensive formal education.

The low barrier to usage can be attributed to the toolsets’ small, but often highly used feature sets. For users experienced with complex enterprise applications, this is a refreshing change. At first seemingly confining, the limited feature sets allow for maximum usability. Tools like Basecamp from 37signals also embody this ethos, providing a small, but often used feature set. This drastically reduces the need for education and increases the rate of adoption and speed at which value can be delivered.

That being said, it is beneficial to offer formal training classes to outline the available functionality of the tool and review how it might be applied through an examination of a series of use cases in order for the end users to obtain the greatest benefit. Once an initiative has been able to conform to the governance requirements for a project, a quick boot camp-style training curriculum led by an experienced user or company teacher is an excellent way to jumpstart the project in an effective manner with minimal resources.

Value

Given the current unmanaged whitespace within organizations, these tools provide substantial value from both a business and information technology management standpoint. Business users are able to realize new value by quickly reacting to their current and emerging business challenges, and authoring solutions for them. Blogging and wiki-style mechanisms provide an excellent platform to facilitate knowledge transfer and knowledge management not possible before, allowing for the actualization of all-important tacit knowledge. Information technology management groups can benefit from cost savings by consolidating some existing, moderately used applications and from a never-before-possible degree of auditing within the whitespace.

Complex decision making

Tools that allow the business to paint a canvas of dynamic collaborative functionality allow for an endless possibility of “applications” to be created. Imagine a situation in which a major decision needs to be made among a number of players from across the business. The decision might hinge on information from a CRM, ERP, or custom application. This critical data can then be incorporated into a space where users can contribute to a wiki or share documents and various other artifacts around the data to ultimately make a decision or select a strategy on the matter. This would have historically happened in a disjointed way across email where the process would take longer and the knowledge work potentially would be lost beyond the final decision.

Collection of tacit knowledge

The creation of a low barrier to the collection of tacit knowledge cannot be understated and can have a direct impact on the bottom line of a business. Imagine a vendor consulting group that is helping to increase product sales. Ensuring their field methodologies, such as best practices and critical product issues, are easily captured and shared among resources, can have a direct impact on deployment success. This deployment success translates literally to increased customer satisfaction, which, in turn, increases product sales.

Value through iterative contribution

User-driven authoring really shines when we examine how quickly we are able to realize value throughout a project. User-driven collaborative frameworks accelerate the time in which business value is delivered due to the ability to iteratively author. Unlike building with traditional software, requirements do not need to be completed for the business to begin constructing a solution. This allows business users to continuously focus on small, high-value components, which lets them realize value early and often throughout their process.

Cost savings and control

As IT departments attempt to keep costs down and monitor what transpires within their systems, controlling application sprawl is a top priority. We can look toward these new tools to act as a platform for consolidation of existing, lightly used legacy applications. This reduces cost not only from a server perspective, but also from a code maintenance perspective. Potential “would have been” custom development initiatives can now be handled through the framework. This can also stunt ongoing development maintenance costs as development efforts can now be directed at furthering core elements of the business and not providing the “one off” solutions that the user-driven collaborative suites now fulfill.

To measure the value that the suites deliver, key performance indicators such as email usage, the amount of resource and time to onboard a new employee, and the length of time to resolve a problem or complete a research assignment can all be captured. Additional quantifiable justifications can include servers and the knowledge, staff, and time to maintain many small, infrequently used systems.

Final Thoughts

Enterprise 2.0 collaboration suites are an investment in an organization’s production capacity. The possibility of being able to harness and navigate whitespace within organizations through business user-authored environments is an exciting, powerful vision. To drive these efforts and expose new business value, both education and governance must form the pillars that the newly created solutions will stand upon. In addition, a business champion must be able to firmly grasp these concepts and understand that value will not be delivered on the basis of the toolset’s features, but on solving key business problems and using the toolsets to manage the solution. With this foundation we are on our way to unlocking the value of enterprise 2.0 collaboration technologies.

* Originally published on BEA System’s Arch2Arch 03/05/2008

Over a series of various online community and corporate intranet deployments, heuristics have emerged as to what will make the community a “success” and provide a return on the investment. These heuristics can be used with a broad array of deployments within your corporate platform to gauge what business value is created for the end users of the platform.

These guidelines can be condensed into a workbook format to help us to understand and prioritize development activities on the basis of the value that they provide. The workbook includes a series of questions that fall into five basic categories outlined below.

• Content – knowledge workers require access to various documents and materials that are analyzed and synthesized in order to perform their job functions.
• Process – a task or series of related tasks that can be represented as a workflow that workers need to interact with at some frequency in order to perform their job functions.
• Access – can potentially present a barrier to use if complex or redundant authentication to systems is required.   Conversely, if multiple systems become available from a single authentication value in the form of time savings can exist.
• Application – various line of business systems are critical to employee’s ability to perform their jobs.   This category relates to these tools that are often specific to collecting and referencing data for a particular department or job function.
• Time – acts as a well understood, easy to convey metric to evaluate possible savings from projects.*

*Please note that this workbook will only touch lightly on time savings.  Time savings is a byproduct of various efficiencies that an intranet potentially offers users.  The workbook focuses on the underpinnings of what delivers the time savings.

The workbook has a variety of line items associated with each category. Within each category there are groups of line items that need to be marked with a y or n indicating if they are applicable. For each group select only one line item can be answered. As the workbook is completed a running tally is displayed in the upper right hand corner of the sheet. If when finished the score is above zero – the project that you have outlined will provide solid business value and give your end users a compelling intranet space.

Download Intranet Success Workbook

I would be interested in feedback on the workbook, as there are many additional line items that could be added.

If you have never read Seven Habits of Highly Effective people you are missing out – especially when it comes to making the most out of an investment in portal. Specifically, I am referring to the concepts of stewardship delegation and production capacity, both of which can be developed through an educational curriculum and guidelines aimed at empowering business users. Simply put, in order to gain the most value from a portal deployment the business needs to understand how to fish.

Stewardship delegation places the responsibility for project results onto the business participants. This ability to participate is gained through platform education and agreed upon guidelines for contribution, thus increasing their production capacity, commonly known as effectiveness. This will maximize the return on the technology investment.

Although at first intimidating it is possible to grow production capacity within the user base via a formalized gating process users. In order to have business needs met through the portal the business must actively participate in some educational offering and obtain rudimentary levels of knowledge with the toolset, before being allowed to complete the deployment of their project. This process should be mandated by way of portal governance. With this being said it is understood and accepted that a less mature portal deployment might not have a robust governance framework yet in place and we may need to begin the process of education with more pragmatic measures.

Common Roadblocks to Building Production Capacity
Beyond executive sponsorship the primary roadblock to building production capacity generally sits with the fallacy that the portal team “cannot afford to take time” to educate their user base how to self-serve. Remember that we need to focus on effectiveness, not efficiency. It will always be more efficient to have the portal team do the work directly, but it will not scale. We need to build effectiveness.

This is somewhat akin to owning a race car, but never taking time to learn how to drive the car properly – you have made the investment, but will never unlock the full potential of the investment. This is why investing in an organization’s production capacity makes so much sense. The portal team can still continue to produce results for the business, but some of their time needs to be spent building the production capacity of business teams themselves.

It may seem obvious, but this approach goes a long way towards
• Allowing the portal solution to scale throughout the business
• Providing faster response times to business needs
• Allowing the portal team and development staff to focus on more strategic initiatives and less day-to-day management of the platform

The beauty of this model is that after experiencing success with it the business is unlikely to want to wait on the portal team to laboriously build out solutions that they can configure themselves. Just imagine a solution development system where a portal team spends more time developing reusable or strategic components and evolving the governance model!

Getting Started with Stewardship Delegation
In the book Seven Habits of Highly Effective People the concept of stewardship delegation is introduced and is alarmingly similar to portal “Governance”. This style of delegation takes time and patience on the part of the educator, but the end result is a rewarding relationship where the student (the business) walks away able to effectively contribute to solutions. You may ask why this is different that any other form of education. Good question!

Per the Seven Habits, Stewardship Delegation requires an up-front mutual understanding of and commitment to expectations in five areas. The following areas are taken from Seven Habits of Highly Effective People and updated to directly relate to portal initiatives.

1. Desired Results – Have the person see, describe, make a quality statement of what the results will look like and by when they will be accomplished with their project. This should be achieved through a formal request stating the mission of the initiative, that is vetted before a portal steering committee or project approval board.

2. Guidelines – Identify the parameters within which the project group should operate. Keep the responsibility for results with the project team that has been empowered. This should include the responsibility for participating in a portal education session. The project team should not be able to commence work until they have completed the education session and had their project request approved.

3. Resources – Identify the resources available to accomplish the required results and who will maintain the solution once it has been created. Although seemingly simple, long term ownership can be very challenging. When solutions are built without clearly defined long term ownership they detract from the end user experience, cluttering it with out-of-date or irrelevant content.

4. Accountability – Set standards of performance to be used in evaluating the results and specific times when evaluation will take place. This represents a layer of governance present in more mature portal deployments that should be placed around any project that is undertaken within the portal.

5. Consequences – Specify what will happen as a result of the evaluation, including rewards and penalties. In the above example this might relate to the community being discontinued if traffic levels fall below a certain level. These metrics need to be agreed on by the parties ahead of time and will be used to ensure that the project outputs (perhaps a community) stay on track well after completion.

Governance is complex and the above illustration of the five areas only scratches the surface for what is needed to successfully run and manage a portal deployment. It is clear, however, that the common thread is the participant’s commitment to agreed-upon desired results.

My hope is that the above elements can jump start a more formalized approach to deployment success within an organization. The participants realize that they need to be place genuine commitment behind their initiatives, but also understand that they will be rewarded with the ability to have a generous degree of autonomy and control over their projects if they commit to the five areas above.

Going Fish – Making it Happen in the Real World
It is obviously easy to write about the merits of the above model when we seemingly find ourselves constantly bailing the water out of our canoe so we do not sink. Just as when we are working diligently at jobs there is never a “good” time to take vacation – but we just need to do it to protect our production capacity.

Once an organization has made an investment in the portal platform it would be doing itself a disservice not to start engaging in stewardship delegation to enable its user base to increase its production capacity through education and adherence to agreed upon guidelines. The following items represent some practical steps and guidelines to help begin the journey of increased production capacity

• Design a community request form that addresses each of the five areas highlighted in the “Getting Started with Stewardship Delegation” section above

• Find a request suitable for a pilot project that the portal team can mentor the business team to develop themselves

• Make it mandatory for anyone who requests a community to actively participate in a portal 101 class and demonstrate a fundamental understanding of the toolset

• Hold lunch and learn workshops to enable business users to get a better sense of what business value can be provided by the platform and where it has been successful in the organization

• Develop a community that contains a wide range of sample portlets so people can get a sense of what platform tools exist to meet business needs

Implementing the above concepts through stewardship delegation will go a long way to ensure that an educated, empowered business team has an optimal production capacity and can make the most out of the portal investment. This will allow the portal team to then focus on developing the vision and strategy necessary to continue to support new solutions for the business in a timely, effective manner, making the most efficient use of portal.

The group covered Facebook application architecture, use of Facebook Markup Language (FBML), Facebook Query Language (FQL) and Facebook APIs. During the session the team reviewed a sample application in detail that used FBML and the API to merge Facebook data with a standard PHP / MySQL application to provide user profile information, a comment system and filter database results only created by the friends of a user. The full source code (PHP code and SQL to create the database) of the application is posted below so that people can get started with their own application development.

View more details of the meeting

Download Sample Application

Do not forget to download the PHP client libraries that will let you use the API. To download the libraries go to http://developers.facebook.com/get_started.php and click on PHP Client Libraries. Please note that these will need to reside in a directory alongside the sample application code.

While the potential benefits can be substantial, there are some serious questions that an organization should consider before embarking on SOA and BPM implementations. For instance, will the organization be better served by making use of coarse-grained services developed in an effort to promote SOA, stringing these services together to create process-based applications? In the absence of an additional mediation layer, will it be possible to leverage BPM exclusively to create a wrapper for the interaction into various backend systems?

Additionally, what will happen if BPM and SOA tools are used in concert? Is this a win-win scenario, or an investment into yet another set of tools that complicate information management and application delivery within the enterprise? Do the potential benefits of BPM and SOA span beyond the obvious, where one tool handles orchestration and the other provides service management?

Only through a candid examination of the relevant BPM and SOA tools can these questions be sufficiently answered. And only after identifying the distinct value propositions of these tools can the overlap and synergies their use makes possible be examined.

It is possible to arrive at a three-way intersection of value (Figure 1.1) where SOA is made richer and more relevant in supporting core business objectives. With a SOA structure dictated by top-down design derived directly from business process needs, invoked services can now be linked to KPIs, and detailed service usage information obtained from BAM, along with a layer of compliance, can be woven into the SOA. As a result, SOA partnered with BPM provides greater value than stand-alone SOA, since that partnership makes BPM more agile and resilient. In addition, BPM supported by SOA can benefit from a rich pallet of services bolstered by SLAs and nutured through monitoring, which ultimately eliminates the fragility of point-to-point integration to provide a previously impossible level of stability. This will ultimately help to finalize the three-way intersection of value at which businesses can more easily focus on using IT systems to increase revenue and customer satisfaction, speed product development, reduce process times, and drive growth.

Accelerating Business through BPM

As is the case with SOA, BPM does not refer to a specific technology. It is a methodology for managing, measuring, executing and optimizing processes within an enterprise to help achieve business goals.

BPM has its roots in ERP and similar tools designed to enforce and manage processes within an organization. These tools soon made it apparent that although helpful, they tended to foster rigid process models that were not appropriate for all businesses or situations. In contrast, BPM excels at pulling the business rules out of code, thus speeding development and allowing businesses to model and integrate their processes in a more cost- and time-effective manner. A good example of this is dynamic exception management, which until now may have been impossible to create within a reasonable timeframe and budget. There is little doubt that BPM tools today will become staples within IT organizations given the level of value that they provide.

A wide range of software vendors have created tools to assist in this endeavor. Some of these tools focus on managing people oriented processes, decision making processes, document management processes and/or system integration-centric processes. They generally provide an orchestration layer that ties into and leverages existing technology investments, thereby supporting an organization’s business while providing an analytical layer around processes to trigger alerts and provide insight into trending data. Unfortunately this often means developing potentially fragile, point-to-point integrations to include these systems within processes. Initially this approach will allow processes to achieve coordination and management across silos, but over time this strategy becomes challenging as enterprise information systems evolve, making it difficult to manage existing process integration points ? if not outright breaking them.

Infrastructure Enablement with SOA

Among enterprise software buzzwords, SOA may be the biggest. A SOA strives to encapsulate and manage discrete business functions into services that can then be used for enterprise application development.

As enterprise information systems evolve, it is unrealistic to expect them to continually adhere to certain standards, beyond the use HTTP and other basic transport protocols. This is where an Enterprise Service Bus and a Data Service Layer are extremely useful. They help bridge disparate protocols and formats, enable service management, promote service reuse, and can provide a single interface into a series of potentially heterogeneous platforms. Going one step further, they can provide tools for service lifecycle management, enforce SLAs to offer stability, and provide detailed monitoring data, making them an ideal choice to manage enterprise data and systems.

As the industry evolves, companies face new challenges, including software as a service (SaaS) and the management of services outside of the corporate firewall, the consumption of REST and other new technologies and methodologies, and the management of complex security brokering. In this ever-changing environment, a strong SOA can help companies remain agile and responsive to business demands.

But SOA by itself provides no way of orchestrating these services to onboard a new customer account or employee, handle a service request, or manage a loan origination process. Applications may be able to tie directly into a SOA, but that isolates the business logic onto various islands, hampering reuse and creating rigid systems in which the business has a limited ability to participate. This decreases the power and speed with which domain expertise can be applied to systems. SOA also provides no native mechanism to surface relevant, business consumable analytics to users of SOA-based applications.

Creating a High Value SOA

SOA’s value proposition is impressive, but figuring out where to begin creating components for a SOA can be a challenge. It can be overwhelming to face the prospect of creating a service portfolio to support business needs while inadvertently building dormant services that can drain resources and budgets that could be used elsewhere.

BPM can be an ideal catalyst to create a high value SOA because it drives a top-down approach to the development of coarse grained services, and can be instrumental in helping organizations realize a business-driven SOA. Every service developed in this manner will inherently tie directly to a process that supports the business. This forces services to bind back to core organizational objectives, promoting a level of alignment to a business’s value chain that other combinations of technologies are unlikely to deliver. This factor allows BPM to maximize the value of SOA.

Robust Business Process Management

The enterprise is constantly in flux. Though there are some trends toward communication standards with Service Component Architecture (SCA) and other methodolgies, it is unlikely that systems will develop and maintain a uniform approach to communication and data exchange. It is far more likely that the specifications and delivery mechanisms will fluctuate or evolve, as will the services themselves, making service lifecycle management and mature approaches to service management increasingly important.

By using an Enterprise Service Bus and other staples of a SOA it is possible to pragmatically link various elements within the enterprise through a mature, resilient fabric. This not only insulates BPM processes that may be tied to underlying systems, it also lets an enterprise leverage its existing familiarity with toolsets, masking underlying system complexity and allowing all groups within an organization to quickly add their systems to processes benefiting from the SOA.

Ultimately this will allow IT resources to focus on delivering business value on the basis of domain expertise and process modeling abilities. It will also allow those resources to worry less about protocols, messaging and the changing platforms that underlie their processes.

Conclusion: BPM and SOA in Concert

When BPM and SOA are combined, process modeling becomes the face of SOA, helping IT teams to become more agile, and allowing them to more quickly meet the needs of the business by placing a highly flexible management layer beneath their processes. Instead of focusing on binding rigid systems together, it is possible to shift the focus to driving revenue, increasing customer satisfaction, shrinking product development cycle times, and other core business objectives. BPM helps organizations design practical service-oreinted architectures by reducing the ambiguity in the effort to develop coarse grained services within those architectures. This top-down, BPM-driven approach allows business needs to dictate the direction of service development.

There are other tangible benefits to be realized when driving SOA innovation with a top-down, BPM-guided approach. In that scenario, a SOA can benefit from metrics in the form of KPIs, rich analytics around service usage through BAM, and a wrapper of compliance management that would be impossible with standalone SOA. A rich SOA fabric naturally reciprocates, providing BPM with a rock-solid foundation built on top SLAs, detailed low-level monitoring, and stability that allows processes to isolate themselves from changes in underlying systems.

Both BPM and SOA provide substantial benefits to an IT organization, but it is clear that when used in concert an entirely new level of value can be achieved to help an enterprise remain agile, flexible, and focused on driving core organizational goals with IT.

Originally posted on Oracle Technology Network Sept 2008

It is time to revisit business analysis basics and be careful to make sure we have not started focusing entirely too much about the perceived need for these tools, opposed to a specific need. These tools are powerful and attractive, but we really need to understand if and how these technologies should be leveraged – pinpointing where they can alleviate business pains. In the work that I have done with a range of enterprise software deployments there is a consistent trend demonstrating successful implementations result when done to address a specific need, tools that were put into place because the technology was in vogue failed. Web 2.0 technologies in the enterprise fit the same bill. Do not look to implement them because eWeek magazine or another publication has labeled it as the thing that other IT executives will implement this year.

I hope to clear the air in this post by outlining the virtues of each tool (specifically tagging, blogging and wikiing) and through a series of questions add clarity to where they would make business sense and allow the virtues to be realized.

Tagging
Social tagging technology excels at handling large amounts of unstructured data that is not served by traditional knowledge management systems (i.e. folders upon folders buried in a large, somewhat static hierarchy). Given this power it needs to be considered as part of an overall knowledge management strategy for information workers, but it also needs to specifically address some pain or a specific need of the business.

As information volumes continue to rapidly expand in the enterprise it is very difficult to organize and catalog assets, even with the support of full-time librarians. Additionally, in a world of M&A and constantly shifting organizational structures, it can be all the more important in helping people to reign in and make sense of this data. It is not uncommon for users to spend an extra fifteen minutes searching for an article within traditional search engines when they could not explicitly state their query to return satisfactory results. By contrast, tagging technologies have allowed them to see what other, related categories materials might fall into, speeding their searches drastically. Here are some questions that may help your organization determine if tagging would support the business by meeting specific business needs.

• Is your company currently experiencing quantifiable issues finding documents or other digital assets within your network? Is it a big enough of an issue to act on?
• Is a technology like social tagging something that your organization’s culture would embrace? Is the user base directly asking for it? It is important to keep in mind that tagging will only benefit end users if they are willing to contribute to the tagging of document. As enterprise tagging matures it is likely that it will gain acceptance in much the same way instant messaging has within the enterprise.
• Is there any research or knowledge intensive work at your organization that tagging may accelerate through more effective discovery of information?
• Are there opportunities to use this technology to help external customers more easily do business with your company?
• Would it be possible to designate someone to own and manage the platform from a business standpoint at a department or enterprise level?

Blogging
Blogs are great tools to rapidly publish and share expertise within an organization. Unlike email, a blog posting persists and is generally visible to a large audience which is able to engage the author in a dialog with comments or questions for everyone to see. Unlike a discussion forum, a blog posting provides detailed information around a particular topic, rather than a brief comment or question. A blog is also generally associated with a single person, allowing them to gain recognition in their organization or respective field. In your organization it might be a software developer, operations specialist or researcher that is able to provide a significant amount of value with this tool.

It may sound strange, the key to enterprise blogging is not about creating blog entries to be consumed by the entire enterprise, but about providing a single, unified platform that specific business participants can use to write posts for discrete audiences. Blogging within departments or to specific niches where the information is most relevant is the most valuable use of the technology. One of my prior postings (Niche Cooking for Portal Success) details a philosophy aligned with this approach which will work equally well for blogging. The following questions will help you to identify if it makes for your organization to deploy this technology.

• Do you have experts in your organization that have pointers that others would benefit from in a measurable way?
• How often would there be something that someone would blog about that people across the enterprise could really benefit from? Our foremost needs revolve around what it takes to get our work done, so any blogging that takes place in an organization has to help meet this need. With rare exception anything else is not providing value that can justify putting a platform into place and taking the time to manage it.
• Would connecting with customers, partners or external constituents add value for your business? Would it be worthwhile enough for the investment?
• Would people be allowed to have time to contribute to their blogs during work hours?
• Would your organizational culture be tolerant of people posting with limited supervision?

Wikiing
Due to the allure of ubiquitous knowledge capture and propagation, a wiki deployment requires an extra amount of careful thought as to why and how it will be deployed to the enterprise. Given the potential, as demonstrated publicly by Wikipedia, many companies entertain having a wiki tool whose content expands into all sections of their business. This risk is that this generic, organization wide deployment, would most likely bring little business value to the enterprise and leave people wondering why they ever made an investment into the technology.

Similar to blogging technology, Wikis are going to be most effective when deployed for a very specific reason. A deployment could occur within a department, across departments or even with areas outside of or around the company, but should always tie back to a specific need that the tool is supporting. Wikis do an excellent job of helping knowledge workers collaborate on projects or support a function or process, by capturing tacit knowledge, sharing “facts”, presenting methods and or publishing best practices. Instead of being done by a single user, a Wiki allows a team to work together – enhancing and updating areas to evolve with the business. There is no better “living document” than a Wiki. Take a moment to think about the following questions to see if a Wiki might make sense for your business.

• Does your business have undocumented processes or knowledge that could help a specific department or function perform more effectively if captured in a Wiki format?
• Is there a simple place where new employees could go to learn during an on-boarding process? As policies, procedures or reporting structures and processes change within an organization a Wiki does an excellent job of making sure people can get up to speed.
• Does an identifiable bottleneck exist with some members of your organization that could be alleviated if they were able to share their knowledge collectively with other employees?
• Given the categorization that a Wiki imposes would it make existing knowledge more accessible if placed into the a unified format that a group could manage and edit? Since a Wiki can be an authoritative place for a collection of related materials it requires far less maintenance than a series of disparate files to maintain, enhance and manage.
• Would people be allowed to have time to contribute to the Wiki during work hours?
• Would your organizational culture be tolerant of people posting with limited supervision?

Final Thoughts
There is not doubt that a range of social computing technologies in the enterprise can assist businesses to run more effectively. However, we want to make sure that we do not implement technology in search of a problem. The challenge is connecting them with the business in the right way. Do not find a use for tagging, blogging, wikiing. Find the business need or pain point – then examine what technologies best support meeting that need or eliminating the pain point. Hopefully some of the above questions can help your organization to focus, clarify and be successful with where and how these emerging technologies can benefit your company.

Setting off on a portal deployment or adding elements into an existing portal deployment without a well thought out governance strategy is unfortunately a path to disaster. Do not be fooled into thinking that by virtue of having an enterprise caliber portal platform somehow governance will magically be take care of. Just as with any technology project it takes expert planning to create a solid, long lasting foundation that will make the platform easy to manage.

The good news is that by following some basic guidelines your deployment can start on top of a solid foundation and stay healthy over the course of its lifespan. Implementing proper governance will arguably add a level of overhead, but once your deployment grows beyond a trivial level, it will provide some serious returns and create efficiencies for users who are developing or contributing within the platform. To keep this guide platform agnostic major content or application areas within a portal will be referenced as a “Collection”.

Collection Lifecycle Methodology

1. Request

The Request exists to formally review and approve any collection that a user would like to propose for inclusion. This process is critical, as without it no responsibility is associated with the content and other components that may be created and it is no longer possible to manage the content lifecycle.

a. Define Purpose and Ownership – a clear purpose needs to be articulated for the Collection. This will determine if the Collection and its components are suitable for inclusion within the portal. In larger deployments this portion of the request would be vetted within a steering committee, during regularly scheduled meetings. Within smaller deployments or if this Collection were to be included as a sub section of an existing Collection, the inclusion could be determined by the parent Collection owner. This is generally applicable for a department or functional group within an organization.

Explicit ownership of the Collection is imperative. Not only should a named person be accountable for the Collection and its contents, but the group that they belong to must also have ownership. It is not uncommon for people to change roles or exit an organization and therefore there must always be a parent owner associated with the Collection. This can default to a generic spot within the organizational hierarchy. This spot must be amenable to the responsibility and its duties (see education 1.d below) to this in order to have the ability to create a Collection.

b. Establish Metrics / Success Criteria – it is important to establish metrics and or success criteria by which to judge the collection during audit periods (detailed below in 3.a). This is critical to avoid the danger of having a portal deployment loaded with irrelevant content that complicates navigation throughout the portal and presents challenges around quality and relevance of search results within the portal. One common criterion might be monthly usage or another objective metric. For information that is an “artifact” like 401k information (see “Technical Tips”) it is possible that the content must exist regardless of metrics and its success criteria is simply inclusion.

c. Functional and Technical Specifications – just as with traditional software development, some level of functional and technical specifications are appropriate for the project and should be submitted with the request. Given the broad range of what may be deployed within a Collection there are wide differences in the level of depth that is required.

Generally there are two different classes of specifications that may be needed – one that pertains to an application that will run within the portal and another that relates to content that will reside within it. It is suggested that this is done only to the extent that it will make sense for the deployment and not act as substantial overhead to everyday management of the portal.

d. Education and Time – education requirements are just as important as ownership and success criteria. Any person or department that is requesting a collection must allocate time for the owner to receive training that is verified and commit to allocating weekly or monthly time for that individual to participate in the maintenance and development of the collection items. If this is not possible the Collection request should be denied. In order for any Collection request to be approved the management responsible for the request must allocate time for the Collection owner to tend to what has been created within the Collection.

2. Create

The Create phase is relativity straightforward. It acts as a gate to ensure that the materials being produced conform to the original vision and are ready for release to their specific audience. Generally the Create stage is very specific to an organization’s established development processes, so a rough outline of generic steps is presented below.

a. Create – create the Collection on the basis of what was defined in 1.a and 1.c. The creation should be completed in a development environment or sandbox environment where the Collection owner has the ability to privately test what they are doing without interrupting typical usage of the portal environment.

b. Secure – any security criteria that may have been part of the request in 1.c should be enforced at this point, even if it is being constructed within a sandbox or development area. Leaving this step until a launch into a production environment could create serious unforeseen complications.

c. Check – review what has been developed against the purpose that was outlined in 1.a and 1.c above. If a delta exists between the two – either revisit 1.a and 1.c and update it based on the new needs or adjust what has been deployed to conform to the specifications that were outlined.

d. Launch – if the check stage above has been passed, deploy the Collection to the portal for consumption by the intended audience. The Collection will now enter the Manage phase of its lifecycle.

3. Manage

This stage should be performed on a quarterly basis or as makes sense based on the nature of the collection and availability of resources. It provides an opportunity for the portal to stay current and to continue to provide high quality, relevant material to end users. Although it may seem like a large investment in time, its results prove very cost effective with regard to worker productivity and the aversion of significant costs associated with a deployment that has become unmanageable.

a. Audit – based on the metrics and success criteria that were outlined in 1.b review what has been deployed and how well it has met the expectations that were created for it. If the Collection is not meeting the objectives that were outlined for it should be decommissioned as outlined below in step 4. The audit should also include a review of ownership to ensure that a specific individual is still accountable for the contents of the Collection. Due to resource constraints it is fair that the audits take place on a quarterly schedule or as possible based on available resource levels. The people conducting the audits should be from a Business Analysis role that interfaces with the various groups seeking to build Collections within the portal framework. If the audit is failed for other reasons, such as lack of meta-data on various parts of the Collection, the owner(s) should have a fixed amount of time to correct the issue.

4. Retire

Retirement provides for the methodical removal of Collections or content that have not passed the audit stage. This process has to be completed by the respective Collection owner to avoid any unintended removal of valid content.

a. Close – if a Collection or part of a Collection fails audit or is no longer relevant to the deployment it should be removed from the portal. This is very difficult for most organizations to achieve due to a lack of obvious ownership around content, but there is compelling value to the user experience in doing so. The person responsible for the removal of the Collection or pieces within it should be the owner.

Technical Tips

Even though a technology platform does not automatically provide governance, it can do many things to ease the pain around providing a layer of management on top of Collections. There are a few basic, expedient ways to add a lot of value and reduce the time consumed by the governance process.

1. Owner / Department Information – always associate this information with any Collection and the contents within it. Most portal platforms have the ability to associate meta-data with a wide range of objects. This meta-data is generally searchable and through saved searches or various queries it is possible to filter, sort, view and administer a Collection and its items from this data. This will allow for valueable reports around this information to be quickly created during the audits or otherwise.

2. Content Type (artifact vs perishable) – content generally comes in two forms – artifacts and perishable content. Artifacts are items like annual reports or a dental plan for 2006. They are static and will not change over time. Generally they are needed for reference and have unlimited lifespans within a deployment. Perishable  content might be various project documents that are only relevant for a short period of time before needing to be archived or removed from a portal. Just as with owner and department information, it is extremely beneficial to flag this information to allow content to quickly be sorted and evaluated for removal from the portal deployment.

3. Time Stamping – as mundane as a time stamp sounds it is very useful to help sort and act on content to keep a portal deployment running cleanly. It can be leveraged just as the above 2 elements to assist in report generation and auditing.

Wrapping Up

The general framework outlined above provides a clean, straightforward model to help govern a wide range of portal deployments. Whether the deployment is external or internal to an organization or provides content or applications, it will help any organization to keep a firm grasp on their deployment. Although some initial investment is needed, the usability and management benefits of a properly governed portal deployment far outweigh the effort for ongoing enforcement. If your portal is a crucial tool for your organization it is imperative that a solid governance framework resides on top of it.

When working with powerful, versatile technology it is not uncommon to loose sight of the human element that we need to cater to for success. The “because it can” factor is tough to ignore and often initiatives tend to gravitate toward this. In order for a deployment to be successful, people need to walk away from their experience with added value. Using a restaurant analogy, this added value differentiates the quality of a portal deployment from an outstanding four star meal to an unappealingly average fast food meal.

A Grand Opening
Just as with a restaurant opening, a portal deployment goes through a series of phases that ultimately will determine if the investment (servers and software licensing) is worth it.
1. Grand Opening
2. Quality Assessment
3. Reputation Establishment
4. Patronage Level Establishment
5. Patronage Fluctuation

Grand Opening
When a new restaurant opens its doors people are drawn by a mix of marketing effort and personal curiosity. In our case we are most likely going to get exposure through a corporate email or newsletter that lets people know that a new project has been deployed with the portal.

Quality Assessment
What happens next is absolutely crucial. Users visit, or in the case of our restaurant, people eat there. This might seem obvious, but when we look at a corporate portal it is easy to overlook since we have a tendency to be drawn toward and tout features over the applicability of an experience, or meal, to the individual.

Reputation Establishment
Users need to have a rewarding, compelling experience. With the ability to quickly communicate and multitask via email and other electronic means, people have tight schedules and are generally unwilling to incorporate an additional tool if it does not provide significant value. When they experience the portal deployment they will ask themselves a few simple questions: “Did this make my life easier? Cut down on my workload? Enable a process more effectively that my traditional communication and information management methods?” The portal will not grow or assist the business through its novelty, but by the outcome of this hard, black and white examination.

Based on this assessment a reputation is established about the value provided by the new service within the portal or the portal itself. This provided value is where our target audience becomes so crucial. Did we just cook generic food in an attempt to satisfy a wide range of people? Or did we cook a specialty food that directly targeted a particular group of enthusiasts? The word that spreads throughout the enterprise is based on this crucial experience. It will ultimately come down to either satisfying a small group of people who will become vocal advocates, or frustrating a large group of people with a mediocre experience and creating a stigma around the portal platform.

Patronage Level Establishment
If we were able to deliver a satisfying meal we will have done our job to establish devoted patrons. Having this group of individuals will allow us to have sustained value within our portal deployment.

If we did not provide a good meal, people will say “Yeah, I have eaten there, but it was nothing special.” This means that whatever value we provided was quickly realized and then lost, leaving our organization with an “Empty Portal” or failed project.

Patronage Fluctuation
Assuming that we did provide a good experience for our users by adding value, we will pick up positive word of mouth. This will ideally open a good dialogue between these patrons and our business and technology teams. With this communication channel we can continue to invest in shaping value for this group of users, growing out patronage. Beyond this, as more people become advocates of the platform, we can continue to develop solutions for the business members we are serving and gain even more return from our investment with additional, iterative, focused releases leveraging the portal framework.

Getting the Recipe Right – Tips for Success
Continuing with the restaurant analogy, we need to make sure that when they ask for a soufflé we serve it to them instead of crème brulee (as good as our crème brulee might be). The portal is a “top down” tool and that means the business needs to dictate the direction of development initiatives with these needs. In order to make sure that the platform can best assist in driving us toward our business goals, the following items are imperative for success:

1. Invite Food Critics – Get participation from the business unit that you are targeting. These are the people who will be eating at your establishment. This is about what they need, not the buffet of things that you can place in front of them.

2. Serve Bite Sized Pieces – Remember that small is manageable. Let your menu evolve based on the demands of the business. Do not try to pack it full of choices from the onset.

3. Time Food Preparation – Great restaurants have impeccable timing to ensure that their dishes are served in the proper order and correct temperature. Be sure to heavily weigh the benefits of any major development portion of a project. Having one piece of the project get away from you could ruin an otherwise good project as the business will be eager to complete their meal.

4. Maintain Great Ingredients – Governance is essential to maintaining value for a deployment. Just because we served up a great meal the first time does not mean that we are set and can move on. We need to put controls in place to ensure that the quality of the meals stays consistent or improves over time in order to retain patrons and grow our business.

Final Thoughts
Thinking back to how all of this applies to the overall value that we can provide, it is apparent that a large scale launch, although seemingly impressive, serves up less value in the long run if we are not focused on serving targeted, high value tools to our audience. We are sometimes tempted to do things just because we have the ingredients, but in order to build a thriving business, it is vital that we listen to and deliver the great treats that our customer base is interested in.

The next wave driving business value via tagging is here and it is being done through creative design and deployment. At this point the value proposition of tagging enterprise artifacts by and for knowledge workers is generally understood. Given this, it begs the question as to what additional value an organization can gain if they have invested in or plan to invest in an enterprise tagging platform. With the recent release of enterprise tagging technologies our options have become even more expansive as to how we can interact with our data by way of an extensive REST / JSON based, platform independent API . This new flexibility offers the possibility to leverage tagging as more than just an add-on or nice to have feature, but as the core component for dealing with data within a business application.

Traditional Challenge

Just as a folksonomy provides users a way to impose structure on unstructured data like a flat document collection, with some creative design decisions tagging can be extended to components of a business application that to date have historically not been able to benefit from the dynamic nature of community wisdom – only because of the way in which they were traditionally designed and developed. With a creative approach to application design we can now explore the use of tagging as the foundation of an application, rather than just a tool to augment existing data. Seem crazy? Let me explain.

For this discussion let’s focus on the application needs of the fictional technology analyst company, Socrates Research Institute (SRI). SRI is getting ready to provide a new release of a major research application that they are developing for their business users and reflecting on the challenges presented by their prior version.

The research application was designed on the basis that SRI had a set idea of things that they would like to capture around various research topics. Over time SRI found it very challenging to maintain the system given the quick market changes that can occur within research that SRI conducts. Emerging market trends and new technologies often forced SRI into a position where their prior application left them incapable of tracking and filtering on new data since they were bound by the static design of the system. SRI now knows that they will want to filter and collect data over time in categories that could rapidly change and they will need to adapt to situations that they cannot currently anticipate. SRI is hoping that beyond initial development they can do this without intimate involvement from IT.

New Approach

Driving the SRI research system by way of tagging will make it open ended and able to meet the rapid pace of emerging business needs. Data will now be applied by way of user defined attributes at runtime, enabling a limitless amount of sorting, filtering and consumption of the research without involving IT. How is this done you may ask?

1. The actual research itself will be collected on specific products that they are providing analysis on by way of a reference. In this case it will be a hyperlink to a product page on a vendor’s web site submitted through browser toolbar that interacts with the tagging engine API.

2. For each one of these products, tags will be applied that supply the type, price range, vendor and other information for that product. These tags will be made mandatory and selection will be enforced through the application interface, calling back to tagging REST APIs.

3. Beyond these tags all other information will be applied at the discretion of the research teams. Any additional data from the vendor around their product (PDFs, web pages, etc) can be pulled into the system and auto-tagged, saving time and effort.

Now it really starts to get interesting… once the data is applied to the object of research there are an expansive set of views that can be created on top of this data based on the filtering capabilities for searching tagging data. This means that IT can develop a single component that will allow users to define set views around products, research events and any other criteria that may be collected based on the context that the component is used in.

Ultimately the data can be presented based on filtered queries to give the end users very traditional application views, even though the data is stored within the tagging engine. This can include filtering different views of the data to provide context sensitive interface, drilling down into the data to provide more refined views and reporting on data that may be relevant to a certain, product, event, market condition, etc.

Final Word

There are many possibilities for application design and development using a framework as I have outlined above. Leveraging a tagging system as an application platform allows for a highly dynamic, user driven, application experience – while cutting down on development and maintenance costs. If you are curious about seeing how this approach might work for your next project, drop me a line and I would be more than happy to brainstorm around it.