March 2009 Archives

With apologies to S. I. Hayakawa, whose classic "A Semantic Parable" has been a staple of virtually everyone's education for more than a half-century.

Not so long ago nor perhaps all that far away, there existed a need for several departments of a huge organization to share information in a rapid and transparent way so that the business of the organization could be improved and its future made more secure.

Now each of these departments understood and agreed with the basic need for sharing, so no one expected there to be problems achieving the desired results.  Each department had its own IT group, working diligently using best practices of information technology as they understood them. When the need for information sharing among the departments became evident, the executive managers called a meeting of IT, operating managers and lead technologists from each department.  At this meeting, the executives explained that the need for a more transparent and flexible information environment among the departments and with the world outside.  Everyone nodded their agreement.

The IT manager of a major department exclaimed; "what we need is an enterprise information architecture; an EIA." Most of the other IT representatives agreed, and an effort to develop such an architecture was begun right there. The initiating department stated that because it had the largest and most mature IT infrastructure, the EIA should be modeled on technology approaches it was using.  Several other departments agreed--they had already adopted similar IT approaches and could easily participate in such an EIA.  Some other departments, however, having gone down different paths in their IT planning, took some issue with this suggestion. They feared that changing course to come in line with the suggested architecture could seriously disrupt their existing IT plan, funding and staffing.  Although willing to be good citizens, they were mindful that their first responsibility was to their own department.

More discussion ensued, suggesting and examining different IT concepts like J2EE, SOA, SQL, Web-centricity, BPR, and so on.  Several departments that had software capable of supporting it even mentioned XML. Like a Chinese puzzle, the group always found itself just short of consensus, agreeing on the basic concepts but each bringing variations in implementation level, manufacturer, etc., to the discussion.  In the end, tempers frayed by the seemingly endless circular discussions, the group decided to table further action until more detail about the need could be developed. Actually, nearly everyone in the room knew that they probably were, at that moment, as close to consensus as they were likely to get unless the top managers chose and mandated a solution. Anticipating just such a mandate, nearly every department descended on top management to make the case for its particular IT and EIA approaches, or , sensing defeat, for an exemption from whatever the decision turned out to be. The top managers of course, who knew little about the details of IT, were affected most by the size and clout of the departments beseeching them and by the visibility of the IT vendors they touted.  Battle lines were drawn between groups of departments, some of whom even went so far as to turn their vendors loose on top management to help make the case for their approach. Like molasses in winter, the entire situation began to congeal, making any movement-or communication among the departments for that matter-unlikely.  In the midst of this growing chaos, the original need to share information-and the information itself-was almost completely forgotten.

Then, when things looked terminal, someone from a department operating staff suggested that maybe things would work better if the organization just developed and adopted standards for the information to be exchanged and didn't try to develop anything so far-reaching as an entire Enterprise Information Architecture. At first, no one listened to this obviously "un-IT" suggestion, but as things got worse and progress seemed out of reach, top management asked why the suggestion shouldn't be considered.  After much grumbling, a meeting was called in which the staff making the suggestion laid out their ideas:

• First, they said, we should decide what information must be exchanged among departments. We can do this based on our knowledge of the information content itself so we won't need a great deal of technical skill beyond an understanding of the information standard selected.
• Next, we might decide what interchange format will be use to exchange the information. It will be important that this format be capable of easy creation and ingestion by the IT tools in each participating department. XML seems to be a growing interchange format so maybe we should consider XML.
• Then we can document what and how we want to exchange, and publish the documentation to every department so that their staffs can attend to the task of exporting and importing the desired information elements, taking care to avoid asking the departments to use any particular technology to accomplish this exchange, but with the easy availability of XML tools, that shouldn't be difficult.
• Then we may want to set some deadlines by which the various departments must be able to exchange information in the format we choose. That will ensure that the entire effort keeps moving and will help flush out problems that need more resources. Maybe if we just tell them the results we need, they won't be so likely to resist.
• Finally, we ask the various IT staffs to come up with their own technological approaches to the act of sharing: intranet, Internet, VPN, etc. They're really good at this and they should have the say as to how it is done for their department.

After the presentation, there was silence in the room followed by some mildly contemptuous grumbling from some of the IT staff members in the back.

How, they whispered, could a complex challenge like integrating the organization's IT systems into an EIA be dealt with by a few simplistic rules about data formats?   Finally, one of these malcontents gave voice to this objection, to which the presenter replied that the entire idea was to avoid impact on the complex ongoing IT activities of the various departments. The goal, he said, was to articulate what the organization needed in terms of information, leaving the approaches for its provision to each department's IT staff. This, he said, would hopefully provide a level at which consensus could be reached, technologically based consensus having proven elusive for many reasons, some quite serious.

Sometimes, he said, it isn't as important to create the impetus to force consensus, as it is to develop a rationale on which that consensus can be achieved and accepted voluntarily by the players. In the case of our hypothetical organization, there were reasons why the technological lives of the departments would never fully coincide and why each would resist even the weight of management dictates to do so. There were not, however, the same reasons why these departments could not agree on what the organization needed in shared information, if each department would be allowed to support the sharing in its own way.

The group thought about this radical departure from good systems engineering disciplines and began to realize that perhaps some integration challenges cannot be met by traditional (hard) systems and technology approaches--in fact, it may have taken quite some time and more conversations to reach this point. When this had finally penetrated, the departments agreed to base their collaboration on information itself, began the joint process of building needed interchange foundations, actually working with the operating staffs who created, used and understood the information--they chose XML and each department found that it had significant XML resources in the software it already used--and went back to work confident that they would be asked to give up neither their hard-won IT environment nor their autonomy as professionals.

As for the organization as a whole, over the next year or so it saw its information sharing begin to improve, spent relatively little of money doing it... and it was able to continue the practice of having all-hands holiday parties at which the department IT staffers and operating folks spoke to one another.

It was a dark and rainy night. She toiled way past normal quitting time for all but accountants with Securities and Exchange Commission (SEC) filings deadlines looming. Cranking away on her first XBRL SEC filing, Debbie became quite frustrated. "I know what is supposed to go into all of these "other" accounts, but XBRL just doesn’t care," she lamented. You see, Debbie is the accountant who knew too much.

Debbie is not alone. In a recent conversation with Louis Matherne, former XBRL International President and Director, XBRL Services for Clarity Systems, the situation described above is actually a common occurrence for accountants tagging XBRL filings for the first time. He suggested a simple example:

The company balance sheet says "prepaid expenses and other". "Other" is there because it represents several accounts that aggregated to the balance sheet become immaterial as separate items. The registrant, however, knows what it is and thinks they should create a new taxonomy concept that better captures the details of "other". No where in the financial statements or footnotes to the financial statements do they describe what that 'other' is."

The object of using XBRL for compliance with the SEC mandate is to present the company’s required financial statements and footnote disclosures, not to expose the preliminary accounts and internal decisions the led to the final, top level reports. XBRL is not meant to extend, expand or further explain legal filings. It simple puts your disclosures into a machine readable form. The last word comes from Matherne: "XBRL for the SEC is primarily about the disclosure of the accounting".

The US GAAP XBRL taxonomies can be found here.

The Accountant Who Knew Too Much

Over the last few months, I have become acquainted with the wonders of the 140 character “tweet”. For those of you who are not “tweets”, I am referring to the combination of instant message and social networking that has converged at www.twitter.com. In essence, twitter asks “peeps” a simple question, What are you doing right now? In 140 spaces, you can communicate what you are thinking or what you have just read on the web.  Long URL’s are easily truncated leaving enough space to communicate simple messages.  If you find people that are doing or reading about interesting things, you can follow their "tweets".

In efforts to keep up on XBRL, I use Yahoo and Google key word alerts as well as selected RSS feeds from the SEC and others. I have found, however, that this system falls short of the daily updates the people using www.twitter.com are providing for me. Its amazing how effective a 140 character message can be in sending you directly to fresh web content relevant to your interests. To improve my “hit” rate, I’ve added a few Tweet favorite tools such as tweetdeck (www.tweetdeck.com), TwitScoop, WeFollow, and MrTweet. Join up and send me a note. I’d love to follow you!

As the world of technology makes literally breathtaking strides, the world of automation finds itself increasingly focused on the technology. Indeed, in many areas of popular culture, the technology becomes an end in itself, conferring the patina of success on projects that are techno-heavy, never mind that they may not meet their objectives particularly well. This despite the pronoucements of virtually every management authority since the 60's that technology and automation are different and the latter is the most important to success of the organization.

Nowhere is the tendency to focus on technology itself, to the detriment of meeting functional goals, more pronounced than in the general area referred to as "conent management" or CM, and in no part of CM has this tendency more clouded the picture than in the relationship of its semantic components; "Content" and "Management." In today's CM world, the focus on Management means that software and technology takes center stage with an implicit assumption that if one just adheres to the proper technological dictums and acquires the most powerful CM software, the effort will be successful. When efforts so constructed fail to meet their objectives, the further implicit assumption is that the technology... or the technology selection... or the technology governance... or the technology infrastructure has failed. In many cases while some of these may be true, they are not the reason for the failure.

Often, the cause of failure (or marginal performance) is the other side of the CM terminology; the content being created, managed and delivered.  Look closely at many automation environments and you will see a high-performance management and delivery environment being fed by virtually uncontrolled content raw material. If "you are what you eat", so too is a content management and information delivery environment. In fact, failure at the delivery end is more often than not a failure to develop usable content instead of a failure of management and delivery technology. So why, with all the tools at our command, do we not address the content creation portions of our information life cycles?

I don't claim to know all the answers, but have formed some impressions over the years:

FIRST: Content creation and its unwashed masses of authors,  providers and editors has traditionally been viewed as outside the confines of automation planning and development; indeed often as a detriment to automation rather than an integral part of the overall process. With that mentality, the system developers often stay completely away from content creation.

SECOND:  The world of software products and vendors, especially those in the management and delivery space, would rather spend more money on their systems in an attempt to make them resistant to the vagaries of uncontrolled content, of course at higher fees for their products. The world of content creation, if it can be called that, is still controlled by the folks in Renton, to their own corporate and marketing ends.

THIRD:  In most automation projects involving content, the primary resource is the IT group that, while highly capable in many cases, does not understand the world of content over which it does not itself have control. The result is usually a focus on the IT itself while the content creation groups in the organization find themselves outside with their noses pressed against the glass... until they are called in to be told what will be expected of them. The resulting fight often virtually dooms the project as it had originally need conceived.

So what should we do differently?

While every project is unique, here are some thoughts that might help:

FIRST: Understand that technology cannot fully make up for the absence of content designed and structured to meet the functional needs on the table.  Indeed, if it came to a choice between good content and high-performance management resources, content can be delivered with a surprisingly low level of technology while no amount of technology can make up for AWOL content.

SECOND: Accept the premise that well-designed content, fully capable of supporting the functional objectives of the project, should be the first order of business in any major project. With this, acknowledge that the content creators, while they may be less controlled and sometimes not easy to work with, are a critical component in the success of any project based on their output. In many content creation environments, negotiation between what would work best and what can be provided will result in a set of compromises that gets the best possible content within the constraints in place. That done, technology can be applied to optimize the life cycle flow of the content. Note that in this construction, the technology is a secondary factor, supporting but not defining the strategic direction of the project.

THIRD: Despite what you may hear from the software industry and its sales force, understand that in the term "content management", content is the most important component and just buying more technology will not make up for its lack. From this understanding, you will be able to create a balance that accords both content and technology their rightfully important places in the overall effort.

Regards, Barry

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

With the rise of Web 2.0 and 3.0, growing Internet traffic, social networking and a host of other technologically driven applications and appetities, government at all levels is confronting the burgeoning changes in its role and participation in the society around it.

An important part of this process is the separation of the paths down which technology is taking society at large from the paths government should and should not follow in performing its essential functions.   Experience has shown that not every tool, functionality and resource available to and used by citizens should become part of the governance process. The quandry is deciding up front which is which. This quandry can be seen in the very definition of government being used to described the future: "connected government", "open government", "participatory democracy", "transparent government" are just some of the  terms being used to describe what their users think government should be.

The core challenge, it would seem, is to develop an approach that makes government at once more effective in discharging its myriad day to day duties, more open and responsive to the honestly held beliefs and concerns of its citizens, yet still fully capable of discharging its constitutional responsibilities without infringing on or abrogating the rights of its citizens. History shows that this:

• Will not be an easy process
• Will not lend itself to a solution based solely on availablle technnology
• Is likely to be tried unsuccessfully (or disastrously) more than once before we get it right. 

This would seem to dictate that, whatever the technological imperatives, government should be changed carefully, in small steps and with well-considered fallbacks from the paths that turn out to be ineffective or dangerous to our liberties. One way to do this, for instance, would be to focus on those government functions we know are broken and understand how to fix (yes, there are such things.)  Then we could focus on applying new technology in areas where the target is familiar, the outcome more easily measured and the impact is less likely to spin out of control. 

If you know me you will realize that I tend to revisit XML authoring tools and processes frequently. It is one of my favorite topics. The intersection of structured tools and messy human thinking and behavior is an area fraught with usability issues, development challenges, and careful business case thinking. And therefore, a topic ripe for discussion.

I had an interesting conversation with a friend about word processors and XML editors the other day. His argument was that the word processing product model may not be the best, and certainly isn't the only, way to prepare and manage structured content.

A word processor is software that has evolved to support the creation of documents. The word processing software model was developed when people needed to create documents, and then later added formatting and other features. This model is more than 25 years old (I remember using a word processor for the first time in college in 1980).

Of course it was logical to emulate how typewriters worked since the vast majority of information at the time was destined for paper documents. Now word processors include features for writing, editing, reviewing, formatting, and limited structural elements like links, indexes, etc. Again, all very document oriented. The content produced may be reused for other purposes if transformed in a post process (e.g., it could output HTML & PDF for Web, breaking into chunks for a repository or secondary use, etc.), but there are limits and other constraints, especially if your information is primarily designed to be consumed in print or document form.

It is easy to think of XML-structured editors, and the word processor software model they are based upon, as the most likely way to create structured content. But in my opinion, structured editors pay too much homage to word processing features and processes. I also think too many  project teams assume that the only way to edit XML content is in an XML document editor. Don't get me wrong, many people have successfully deployed XML editors and achieved targeted business goals, myself included, but I can point out many instances where an alternative approach to editing content might be more efficient.

Database tools that organize the information logically and efficiently are not likely to store that data as documents. For instance, you may have an financial system with a lot of info in relational fields that is extracted to produce printable documents like monthly statements, invoices, etc.

Or software manuals that are customized for specific configurations using reusable data objects and related document maps instead maintaining the information as static, hierarchically-organized documents.

Or aircraft information that needs to match the configuration of a specific plane or tail number, selected from a complete library of data objects stored centrally.

Or statutes that start formatted as bills, then later appear as enacted laws, then later yet again as published, codified statutes, each with their own formatting and structural peccadilloes.

Or consider a travel guide publisher that collects information on thousands of hotels, restaurants, attractions, and services in dozens of countries and cities. Sure, the content is prepared with the intent of publishing it in a book, but it is easy to see how it can be useful for other uses, including providing hotel data to travel-related Web sites, or building specialized, custom booklets for special needs (e.g., a local guide for a conference, guides to historical neighborhoods, etc.). 

In these examples of what some might call database publishing, system designers need to ask them selves what would be the best tool for creating and maintaining the information. They are great candidates for a database, some application dialogs and wizards, and some extraction and transformation applications to feed Web and other platforms for consumption by users. They may not even involve an editor per se, but might rely entirely a Wiki or other dialog for content creation and editing.

Word processors require a mix of skills, including domain expertise on the subject being written about, grammar and editing, and some formatting & design, use of the software itself, etc. While I personally believe everyone, not just teachers and writers, should be skilled in writing well and making documents look legible and appealing, I realize many folks are best suited for other roles. That is why we divide labor into roles. Domain experts (e.g., lawyers, aircraft engineers, scientists and doctors, etc.) are usually responsible for accuracy and quality of the ideas and information, while editorial and product support people clean up the writing and formatting and make it presentable. So, for domain experts, it may be more efficient to provide a tool that only manages the content creation, structuring, linking, organization, etc. with limited word processing capabilities, and leave the formatting and organization to the system or another department or automated style sheets.

In my mind, a Wiki is a combination of text functionality and database management features that allow content to be created and managed in a broader Web content platform (which also may include static pages, search interfaces, pictures, PDFs, etc.). In this model, the Web is the primary use and printing is secondary. Domain experts are not bothered with concepts like page layout, running heads, tables of content generation, justification & hyphenation, etc., much to the delight of the domain experts!

I am bullish on Wikis as content creation and management tools, even when the content is destined for print. I have seen some that hide much of the structure and technical "connective tissue" from the author, but produce well formatted, integrated information. The blogging tool I am using to create this article is one example of a Wiki-like interface that has a few bells and whistles for adding structure (e.g., keywords) dedicated to a specific content creation purpose. It only emulates word processing slightly with limited formatting tools, but is loaded with other features designed to improve my blog entries. For instance, I can pick a keyword from a controlled taxonomy from a pull-down list. And all within a Web browser, not a fat client editor package. This tool is optimized for making blog content, but not for, let's say, scientific papers or repair manuals. It is targeted for a specific class of users, bloggers. Similarly, XML-editors as we have come to know them, are more adept at creating documents and document chunks than other interfaces.

Honestly, on more than one occasion I have pounded a nail with a wrench, or tightened a bolt with the wrong kind of pliers. Usually I get the same results, but sometimes it takes longer or has a less desirable result than if I had used a more appropriate tool. The same is true for editing tools.

On a final note, forgive me if I make a gratuitous plug, but authoring approaches and tools will be the subject of a panel I am chairing at the Gilbane San Francisco conference in early June if you want to hear more. </>