Information Technology Aligned» Information Technology Aligned – Portal, Intranet, Governance, BPM and SOA

Misconceptions – Redesigns and Information Architecture

John Brunswick — Mon, 02 Nov 2009 06:29:55 +0000

In the world of web site management and development, the term “redesign” may at first seem harmless, but can have far reaching implications as to what will be done to deliver a successful project. I recently worked with a customer who was interested in redesigning various internal and external web sites for their organization. It quickly became apparent by observing their discussion that they were asking for something much broader than an exclusively aesthetic redesign. The word “redesign” is often generically used to refer to an updated look of a public web site, intranet or extranet. Unfortunately the expression “redesign” can be misleading about the actual work that will be needed to deliver a finished project and should alert anyone involved in the project that a much deeper understanding of the project needs much be gathered. This dangerous vagueness can been seen as the equivalent of someone telling you that you must pack for a trip, without knowing anything about the duration or destination.

Most major update efforts to a web site generally involve substantial work around “information architecture” that is combined with a visual “redesign” to meet the overall project goals. To complicate matters further there is also the possibility that the overall business messaging of one of more portions of the site may change. For the purposes of this discussion, we will only focus on the differences with design and information architecture from an implementation standpoint. This will help us to introduce formal, industry standard terms that will specify what is required to deliver a project.

To explain the various disciplines that go into a “redesign” it helps to think of a visitor’s experience at an art museum. The following aspects of a museum will help to map the analogy to the industry specific terms of User Experience (UX), Information Architecture (IA) and User Interface (UI).

Attributes of an Art Museum

Wings – analogous to major, top-level navigation on the site
Exhibits – can represent minor navigation that is dependant on what site area a user is in
Pieces of Art – content / applications that a user may interact with
Visitors – users

User Experience (UX)
The Information Architecture and User Interface disciplines both fall under the umbrella of User Experience (UX). Think of UX as how a museum visitor has perceived, learned and used the museum – or more simply – their overall experience. Visitors may not remember specific exhibits within a museum, but may recall that it was a pleasant experience. Within that pleasant experience there were a series of objective elements created that perception. Those elements are Information Architecture and User Interface.

In the world of corporate web site UX this equates to a site that is at its most fundamental level easily navigable, aesthetically pleasing and allows a user to achieve their goal of their site visit with minimal interference. In order to achieve this a solid information architecture and user interface must exist. When the word “redesign” is used for a project it will almost certainly involve both of these elements.

Information Architecture (IA)
Information Architecture dictates how the various wings of the museum are laid out and where various pieces of art are displayed within the wings. IA helps visitors to arrive at various focal points throughout the museum by way of a logical paths. To create logic paths, many museums lay out their exhibits by geography or time period. This helps visitors to enjoy some level of continuity throughout their visit.

IA helps connect users to content and or applications that they require based on their needs. IA can be simple or complex in relation to the diversity of content and actions that a user will experience during their site visit. IA is by its very nature organic and will change over time to continue to try to meet the needs of an organization’s constituents.

IA is like a blueprint of the museum or an upside down tree diagram that attempts to group exhibits and their contents in some logical manner, helping people easily locate them. Somewhat unlike the physical world, sites can allow visitors to arrive at one particular content item or application from a variety of paths.

User Interface (UI)
As visitors locate their areas of interest within the museum and walk through various exhibits they will constantly interact with singange. Museum signs can come in a variety of styles, are potentially highlighted by lighting and can be placed at a wide variety of places throughout the rooms. Rooms can also be painted different colors and contain many types of molding and flooring. Perhaps some exhibits allow visitors to press levers or buttons to engage audio recordings about various works.

UI allows users to interact with and consume underlying content and applications (art / audio) that are grouped together based on the IA that was addressed in the prior section. The UI sets the visual tone for the site – colors, fonts, positioning of various content and or application on the page. A good UI supports maximizing the value from IA underneath it. A visitor to a museum is going to most likely want to visit a specific set of works and be exposed to reference materials around each one of them. The optimal UI will help the visitor to maneuver and consume this with ease.

To further elaborate on this - leaving our museum analogy for a moment – it helps to think of the variety of MP3 players on the market. The Apple iPod is arguably the premier device on the market for variety of reasons, one of the strongest being its very easy to use UI. The iPod lets music listeners quickly and elegantly access their music.

Closing Thoughts
The next time that someone talks about doing a site “redesign” stop to contemplate what is really being requested. Most often a redesign is not purely aesthetic. As organizations change and grow it is essential that they continue to make their online efforts as effective as possible in supporting their businesses. This means that the User Experience will need to be supported by great Information Architecture and User Interface implementations.

Share this Post

Business Value – Minimal Investment, Maximum Impact

John Brunswick — Tue, 06 Oct 2009 04:24:25 +0000

Looking at web technology it is easy to feel that great business value and user productivity can be gained from creating deep, complex integrations presented through elegant user interfaces. This could be the truth, but it is often far from it.

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

Extend the data model of the base system to account for the new reporting needs
Develop a presentation layer to gather the relevant information for the business users based on this data model
Create a presentation layer to allow executives to view and sort the information
Integrate the presentation layer into their intranet
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

Configure the data model and forms relevant for the data collection around the business needs
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.

Share this Post

Intranet Content Maintenance Tips

John Brunswick — Tue, 14 Jul 2009 16:35:38 +0000

Anyone familiar with intranets knows the pain of not applying best practices to content maintenance strategies upfront in an initial deployment. As part of a governance plan (link here) it is essential to design the maintenance strategy early on in a deployment.

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.

*** link here to various articles that I have done about this ***

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.

*** link to article here ***

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.

*** link to governance article here ***

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.

Anyone familiar with intranets knows the pain of not applying best practices to content maintenance strategies upfront in an initial deployment. As part of a governance plan it is essential to design the maintenance strategy early on in a deployment.

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.

Share this Post

Principles of Natural Participation

John Brunswick — Wed, 17 Jun 2009 00:42:42 +0000

* Originally published on BEA System’s Arch2Arch Community December 2007 and Portalsmag.com

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.

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.
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.
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.
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.
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.
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.

Share this Post

Unlocking the Value of Enterprise 2.0 Collaboration and Authoring Tools

John Brunswick — Tue, 16 Jun 2009 00:03:54 +0000

Enterprise software vendors now include Web 2.0-influenced product suites with blogging, wiki, and mashup functionality. Some vendors attempt to provide programmatic development tools to incorporate these new features, while others have created end user-centric authoring environments.

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

Share this Post

Intranet Success Workbook – Winning is not a Guessing Game

John Brunswick — Mon, 15 Jun 2009 19:05:18 +0000

Launching a corporate intranet or new initiative within an existing intranet requires investment in the form of labor and capital. Before allocating time and resource to deliver a project, wouldn’t it be nice to understand if it has an opportunity to contribute positively by adding business value? Fortunately, achieving intranet project success from a business standpoint does not have to be a guessing game.

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.

Share this Post

Maximizing Portal ROI – Education, Production Capacity and Stewardship Delegation

John Brunswick — Sat, 13 Jun 2009 23:23:19 +0000

“Give a man a fish; you have fed him for today. Teach a man to fish; and you have fed him for a lifetime”
-Chinese proverb

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.

Share this Post

Portal Governance – Solid, Long Lasting Foundations

John Brunswick — Tue, 02 Jun 2009 03:06:55 +0000

If you were going to live a house, wouldn’t you want it to be built on top of a solid foundation that underwent periodic inspection? For whatever reason it may be easy to get the impression that a particular technology platform will inherently take care of governing portal deployments. After all – mature portal platforms have security, user groups and taxonomies that a vendor indicated will help govern the content, right?

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.

Share this Post

Niche Cooking for Intranet Success

John Brunswick — Sat, 13 Sep 2008 00:37:49 +0000

Creating a winning recipe for an internally facing corporate portal is a daunting task. At the onset of a project there is a natural tendency to think that having a large target audience is the route to success and value. What has been found through practice though can actually be quite the opposite. Whether we are experienced with portal deployments or not, there are some fundamental dynamics that if carefully orchestrated can help to ensure a deployment’s success.

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.

Share this Post

Tagging for Business Applications

John Brunswick — Thu, 05 Jun 2008 20:24:17 +0000

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.

Share this Post