Curated for content, computing, and digital experience professionals

Day: March 17, 2009

You too Can Have an Analyst on Demand

A couple of years ago the Gilbane Group rolled out a service it calls, Gilbane Analysts On Demand. The idea was that a company could subscribe to access to Gilbane’s lead and senior analysts for an unlimited number of short calls each year, across all the practice areas. I championed the idea and have suggested it as a good service for start-up content and search related companies. It is a good way for them to pick the brains of experts who have a lot of experience in their particular market niche or to cast about for a different perspective on how they might better approach their marketing, product expansion or services. I’ve had questions related to positioning, possible names or “tag lines,” pricing, and the type of partners a company might want to seek. I also encourage clients to talk to me about “what customers want” in terms of packaging and delivery. In 30 minutes to an hour, a lot of valuable information can be conveyed and, as an analyst I love helping companies think through a solution efficiently. Sometimes, just talking through the issue brings them to an obvious answer or to a better question to have answered. Business guidance seems to prevail over “enterprise search.”

Now that we have had a little experience with this type of service, I have decided that it would serve technology “buyers,” just as well. The service might prove even more effective for some companies than a lengthy contract for consulting services. Companies devote long lead times to thinking about, budgeting, selecting and procuring software solutions. Most of them don’t want a consultant waiting in the wings for the next evolution in a project. What they would like is an expert they can turn to at each project gate where a pivotal decision needs to be made, or for a little guidance on an approach or what the next step should be. As an analyst, talking to technology customers is valuable because I can hear customer thoughts and ideas about products and companies and then present these as anonymous feedback when appropriate.

The Gilbane Group has a long reputation for product independence. Our sponsored research, white papers and webinars focus on timely topical themes, not product briefings or marketing buzz for a particular client. We help vendors get out educational messages about how they view markets, customer needs, tool implementation and strategies for leveraging technologies. We give voice to the values they espouse as companies. When we work for a vendor, we also share advice about how they are perceived in the marketplace, and how to improve their brand because we believe that good and healthy companies make for a vibrant marketplace.

I’ve been told, “off-the-record,” that, while the Gilbane model is laudable, no vendor believes in true analyst or consultant independence. While I am sorry to hear that this might be the prevailing view, it is like saying that no bank can be trusted because of the current financial crisis. Are you hiding your money under the mattress, yet?
Not only are we a trustworthy resource – we have a lot of good people with terrific expertise. Check out the cast of characters at: Gilbane Contacts and consider how great it would be to have them all a phone call or email communication away. Just a thought.

Management of Content Authored in Enterprise Social Software

Suw Charman-Anderson posted a thoughtful piece with the title Businesses will live to regret their social media ignorance today.  Her main point is that organizations that do not deploy enterprise social software behind the firewall will lose control of information as it spreads through public social media.  This is an oft-heard refrain these days in the blogsphere.

Please don’t misunderstand, I agree with Suw.  If businesses want to retain some control over their information, they should provide secure, enterprise-ready versions of the specific types of collaboration and communication tools that employees want to use.  For example, if the risk of information leakage via Twitter is too high, the organization should deploy an enterprise microblogging application on its own servers (or subscribe to a SaaS offering hosted by a trusted vendor.)

What is especially valuable and somewhat novel in Suw’s post is her recognition of the content management issues surrounding the use of public social media to share corporate information.  She writes,

“…you need to make sure you know how communications using these tools are going to be logged, archived, and made searchable. Mostly, archiving (or logging) is built in, so it shouldn’t be that difficult. Cross-archive search might be a little bit more interesting, but it’s worth your while because more time is wasted in re-finding information than in finding it in the first place.”

Much of the dialog around enterprise social software has rightly been on connecting people to other people and the information and knowledge they possess.  The notion of using software to connect people to unstructured information hasn’t gotten nearly as much attention in the Enterprise 2.0 discussion.  Perhaps content management is a dull topic in comparison to connecting people, but enterprise social software is essentially a content authoring tool and it has fueled growth in the amount of content created within an organization.

Traditionally, unstructured information has been housed in what most would call a ‘document’, but it also may be contained in a message authored in a microblogging, wiki, or instant messaging application.  Those messages must be stored, indexed, and searchable so that users can find valuable information after it has initially been documented and shared by the author.  The same content management principles that we’ve applied to corporate email must also be used to ensure the findability of information generated in and shared via enterprise social software.

What is your view on this issue?  Do you have horror stories or best practices to share?  If so, please do by adding a comment below.

XML and Belly Buttons: How to “Sell” XML

Anyone who works with XML has probably had to “sell” the idea of using the standard instead of alternative approaches, whether as an internal evangelist of XML or in a formal sales role. We have developed some pretty convincing arguments, such as automating redundant processes, quality checking and validation of content, reuse of content using a single source publishing approach, and so on. These types of benefits are easily understood by the technical documentation department or developers and administrators in the IT group. And they are easy arguments to make.

Even so, that leaves a lot of people who can benefit from the technology but may never need know that XML is part of the solution. The rest of the enterprise may not be in tune with the challenges faced by the documentation department, and instead focus on other aspects of running a business, like customer support, manufacturing, fulfillment, or finance, etc.. If you tell them the software solution you want to buy has “XML Inside” they may stare off into space and let their eyes glaze over, even fall asleep. But if you tell them you have a way to reduce expensive customer support phone calls by making improvements to their public-facing Web content and capabilities, you might get more of their attention.

I have been around the XML community for a very long time, and we tend to look into our belly buttons for the meaning of XML. This is often doen at the expense of looking around us and seeing what problems are out there before we start talking about solutions to apply to them. Everything looks like a nail because we have this really nifty hammer called XML. But when CD-ROMs were introduced, people didn’t run around talking about the benefits of ISO 9660 (the standard that dictates how data is written to a CD). Okay they did at first to other technologists and executives in big companies adopting the standard, but rarely did the end consumer hear about the standard. Instead, we talked about the massive increase in data storage, and the flexibility of a consistent data storage format across operating systems. So we need to remember that XML is not what we want to accomplish, but rather how we may get things done to meet our goals. Therefore, we need to understand and describe our requirements in terms of these business drivers, not the tools we use to address them.

Part of the problem is that there are several potential audiences for the XML evangelism message, each with their own set of concerns and domain-specific challenges. End users want the ability to get the work out the door in a timely manner, at the right quality level, and that the tools are easy to use. Line Managers may add sensitivity to pricing, performance, maintenance and deployment costs, etc. These types of concerns I would classify as tactical departmental concerns focusing on operational efficiency (bottom line).

Meanwhile Product Managers, Sales, Customer Service, Fulfillment, Finance, etc. are more geared toward enterprise goals and strategies such as reducing product support costs, and increasing revenue, in addition to operational efficiency. Even stated goals like synchronizing releases of software and documentation, making data more flexible and robust to enable new Web and mobile delivery options, are really only supporting the efforts to achieve the first two objectives of better customer service and increased sales, which I would classify as strategic enterprise concerns.

The deft XML evangelist, to succeed in the enterprise discussion, needs to know about a lot more than the technology and processes in the documentation department, or he or she will be limited to tactical, incremental improvements. The boss may want, instead, to focus on how the data can be improved to make robust Web content that can be dynamically assembled according to the viewer’s profile. Or how critical updates can be delivered electronically and as fast as possible, while the complete collection of information is prepared for more time consuming, but equally valuable printed delivery in a multi-volume set of books. Or how content can be queried, rearranged, reformatted and delivered in a completely new way to increase revenue. Or how a business system can automatically generate financial reporting information in a form accurate and suitable enough for submission to the government, but without the army of documentation labor used previously.

At Gilbane we often talk about the maturity of XML approaches, not unlike the maturity model for software. We haven’t finalized a spectrum of maturity levels yet, but I think of XML applications as ad hoc, departmental, and enterprise in nature. Ad hoc is where someone decides to use an XML format for a simple process, maybe configuration files driving printers or other applications. Often XML is adopted with no formal training and little knowledge outside of the domain in which it is being applied.

Departmental applications tend to focus on operational efficiency, especially as it relates to creating and distributing textual content. Departmental applications are governed by a single department head but may interact with other groups and delivery feeds, but can standalone in their own environment.  An enterprise application of XML would need governance from several departments or information partners, and would focus on customer or compliance facing issues and possibly growth of the business. They tend to have to work within a broader framework of applications and standards.

Each of these three application types requires different planning and justification. For ad hoc use of XML it is usually up to the individual developer to decide if XML is the right format, if a schema will be needed, and what the markup and data model are, etc. Very little “selling” is needed here except as friendly debate between developers, architects and line managers. Usually these applications can be tweaked and changed easily with little impact beyond local considerations.

Departmental application of XML usually requires a team representing all stakeholders involved in the process, from users to consumers of the info. There may be some departmental architectural standards, but exceptions to these are easier to accommodate than with enterprise applications. A careful leader of a departmental application will look upstream and down stream in the information flow to include some of their needs. Also, they need to realize that the editing process in their department may become more complex and require additional skills and resources, but that these drawbacks are more than offset but savings in other areas, such as page layout, or conversion to Web formats which can be highly automated. Don’t forget to explain these benefits to the users whose work just got a little more complicated!

An Enterprise solution is by definition tied to the business drivers of the enterprise, even if that means some decisions may seem like they come at the expense of one department over another. This is where an evangelist could be useful, but not if they only focus on XML instead of the benefits it provides. Executives need to know how much revenue can be increased, how many problem reports can be avoided in customer service, and whether they can meet regulatory compliance guidelines, etc. This is a much more complicated set of issues with dependencies on and agreement with other departments needed to be successful. If you can’t provide these types of answers, you may be stuck in departmental thinking.

XML may be the center of my universe (my belly button so to speak), but it is usually not the center of my project’s sponsor’s universe. I have to have the right message to covince them to make signifiaccnt investment in the way their enterprise operates.  </>

© 2024 The Gilbane Advisor

Theme by Anders NorenUp ↑