Wednesday, September 23, 2009

Security policy for CMS implementations

Something I've been looking at recently is the question of how to create an enterprise security policy for your enterprise CMS (DAMS, etc.). It comes, like many other things, to a question of investment and governance.

Security policy here can be described as access control for different user types in each participating business unit. In a CMS implementation, this would mean access for various editorial and production functions, staff and vendor access levels, and access across business unit content sets.

With an enterprise implementation across many business units, requirements come from two directions. The first is each business unit's requirements. If a business unit has not been part of an enterprise CMS implementation before, however, then they may not have given this much thought, and it may be difficult to document their true needs.

The danger here is that relying only on business unit requirements and maybe a few voices from other areas of the company means that security policy will be developed organically. One of the problems that this raises is inconsistencies with the initial business plan. An enterprise system is enterprise for a reason - and an organically developed security policy might end up reducing access for too many users, which may operate counter to the implementation goals generally. Therefore, perhaps an enterprise policy should be developed and maintained.

But there are dangers in relying only on an enterprise policy too, which will tend toward being heavy handed. Not knowing how each individual business unit works may lead to problems. Some who do critical content development or production work may find they are arbitrarily locked out of their work - causing all sorts of problems in rectifying the situation or in gaining acceptance of the CMS in the first place. In publishing, for instance, with the outsourcing trend has been pursued for many years, some critical functions in the publishing process are done by trusted freelancers or vendors who need high levels of access to content. A policy of arbitrarily drawing a line on specific user types (staff vs. vendor, etc.) may not be realistic with the current methods of doing business.

So the answer seems to be that both the enterprise and business unit security requirements need to be taken into account in creating a security policy for implementation. This may require an initial enterprise policy that clearly states the enterprise requirements, and which contains a governance model for adapting to individual business unit needs. Challenges in actually doing this stem from at first not recognizing the risk in a lack of governance for this issue, and then a lack of investment in analysis. A good analyst will propose an appropriately nuanced security policy and governance model that can be implemented for the benefit of all.

Tuesday, August 25, 2009

data modeling - how useful it can be

I'm very interested in my new work on a selection process for data modeling languages and tools.

To bridge the gap between those who navigate DTDs and Schemas at the line by line level and those who are non-technical editorial types, data modeling diagrams can be quite useful. Also useful for a more conceptual analysis of your content/data, which might reveal some things that you might miss in looking at low level coding.

There are a lot of tools to choose from, and a lot of potential applications, whether looking at physical, logical, or conceptual data modeling, entity relationships, taxonomies, metadata models, and more.

Wednesday, August 19, 2009

A priori systems development rant

Again I have come into contact with a priori requirements 'gathering'. It is worth a general rant because it is so prevalent out there.

Developing a system for end users out of the mind of systems experts alone causes confusion in the requirements process - and holds things up.

Instead, please find out what the stakeholders need and then use your reasoning to deduce an efficient way to achieve those needs. And use this to limit your scope to only what is really required - don't spend money on one additional feature. Justify every feature in writing. And do not, by any means, create a sophisticated state of the art system if it isn't necessary!

The world will be a lot better for it.

Monday, June 22, 2009

What's happening to the workhorses?

Saw a disturbing article in the New York Times yesterday:

A Factory for Words in a Sea of Debt

What is the outcome of so many publishing services companies going under? This is just one of several reports I've heard of companies going out of business. Clearly the major publishers have cut their margins so much that these companies cannot survive when payment is delayed.

It also means a lot of talented people have been cut loose. Will they reform into new companies? Will they now develop loose networks and change the publishing services model? With communications technologies today, like Appingo, it is possible for a freelance model to evolve - even for fairly large projects.

We will see.

Wednesday, February 11, 2009

Organizing my information intake

Now that we've finally dropped all our printed newspapers, and with (a little) extra time to focus, it's time to get my news and information organized online.

First, why did we drop our newspapers? They are still one of the most effective, portable, browsable forms of news (at least until I get a new cell phone or maybe a kindle). But, honestly, I was sick of recycling newspapers, of paying extra for news delivery, especially when the current news deliverer kept mixing up which newspaper we were receiving. Oh, and yes, there was that recent morning where my snow blower was seriously jammed sucking up the Boston Sunday Globe - haphazardly lurking under a layer of snow. Nice. And expensive to repair.

So online we go. Here is the first one I ran into:

MyWired.com I was immediately captivated by this site, which shows various channels of news from syndicated publications around the world. Trash talk aside, it has some great features. For example, you can create a new channel with refined search terms in seconds. I created one for Boston for example, with all news that contains the word 'Boston' - with pretty good results. With more refinement in the search terms and type of content, I'll be able to get just what I want.

MyWired also has a section for premium news, where you can pay for specific content in a subscription or for $1 an article. This might be useful, though I think the rate should be reduced for me to go for it at this time - maybe to 10 cents per article. I'm watching the section for now. $4.95 per month might be worthwhile if this becomes my main news intake.

Finally, it has some community features - put up a profile or share your channels or articles with others. These might be interesting features - especially if folks have put up really interesting or successful customized channels.

MyWired gets my provisional vote on KillerStartups.com, though I'm going to wait and see what else I can find out there. It might need more features and certainly needs to get out there more - only found 2 results searching on Twitter for MyWire - and they are not very relevant.

Will look at something else tomorrow.

Tuesday, February 10, 2009

State of the quest

It's been a long road advancing publishing technology. What started in earnest for me about 10 years ago has become something of a career track. I've played it on many sides, from development to management, to executive oversight, to consulting, to sales. What has remained constant in all of this activity is essentially an intense vision and pursuit of an ideal publishing environment. That ideal environment can be made up of systems, applications, formats, scripts, as well as people, vendors, and processes. But for business purposes, it should be judged as a whole.

It seems worthwhile to briefly review the ideal publishing environment at this time. What are its core features?

1. Frictionless. Content transformation is essentially effortless. Digital and print content of all kinds can be produced repeatedly without the use of manual production (whether performed by editorial, internal production, scripting support, or offshore teams). Producing a publishing product in any required format is essentially effortless once the environment is up and running and configured to do so.

2. Empowering. Empowerment of content developers, such as editorial, to concentrate on their work. This includes the use of the most powerful tools for writing and editing, and the best tools for design or media production. But it also includes an elimination of any production tasks performed by content developers, including file management, routing, tagging, etc. It must be noted, however, that an ideal publishing environment cannot be achieved with a laissez-faire desktop publishing mentality. Though desktop publishing creates the empowerment ideal, it comes at a cost for all of the other features of the ideal publishing environment. Some adjustment of how content producers and others work may be required. Finally, empowerment means that the publishing environment itself should not be so complicated as to get in the way of content development.

3. Immediacy. Ability to publish approved content immediately, with no delay of any kind and no time wasted on content production tasks. This can include no delay of any kind prior to publishing, in passing content from one user or group to another. This does not, it should be noted, mean any additional pressure on editorial or design to produce content faster, though the environment should, when necessary, be able to adapt to a higher pressure situation. It does mean that throughput is the fastest possible required to produce a normal publication.

4. Availability. Availability of content to the right people at the required time. Searching for content should be effortless. Retrieval of content should be at a level of granularity that requires no additional browsing of search results or within the retrieved content itself. Metadata such as rights information should be immediately available at the point of need - including at the point of editing content at any granular level. Additionally, no irrelevant metadata should be provided to users at various points in the process. Finally, availability may mean ease of content access among various devices and software applications.

5. Flexibility. The ability to reuse or customize content at an appropriate level of granularity to create new products. But this can also mean the ability of the environment itself to be quickly reconfigured for new purposes and product types. This in turn implies the ability of an environment to quickly, effortlessly, and iteratively adjust any its components to allow continual improvement of the publishing process.

If these are the 5 fundamental characteristics of the ideal publishing environment, how does your own environment rate? How do the CMS, DAMS, web and desktop applications, rights management systems, etc. that you are considering rate? How do they rate individually, and how do they rate as an integrated environment? Yes, this is more a forest through the trees exercise - how does the forest rate? I would like to propose that your current environment is measured, analyzed and rated in each of these 5 categories. Then you can come up with a strategy for taking your organization to the next level.

Monday, February 9, 2009

Hello World!

Hello world! Time to start a new blog. You can see my previous blogging efforts here.