Science Library Pad

Thomas Homer-Dixon lecture - Ottawa Dec 5 2006

Tuesday, December 5 [2006], 7:30 p.m. - EDITH HOLTOM MEMORIAL LECTURE

Where: Worship Hall, First Unitarian Congregation [Church], 30 Cleary Ave. [Ottawa, Ontario]

"The Upside of Down: Catastrophe, Creativity and the Renewal of Civilization" by Dr. Thomas Homer-Dixon, Director of the Trudeau Centre for the Study of Peace and Conflict. His last book (which he will be signing after his lecture) won the Governor General's award for non-fiction. He is a member of First Unitarian Congregation of Toronto.

This lecture series is in memory of peace-activist Edith Holtom.

Question/answer session & refreshments to follow. Free.

from UUFO blog

Computer Security Day 2006

Every November 30 is Computer Security Day.

While I think of course you need to be worried about virus and network attacks, and you should investigate whether you can get some good software for free either through your ISP or just from the net, don't forget

BACKUPS

If you're going to take anything from Computer Security Day, take it as an opportunity to at least do a yearly backup.  When your harddrive fails (which is inevitable), you will thank me.

This doesn't have to be hard.  Just buy an external disk and drag and drop all your important files to it (e.g. your entire photo, video, audio and document directories).

If you want some more technical information, you can try my page on home computer security, or my

Computer Security Book Store (powered by Amazon.com)

Computer Security Book Store (powered by Amazon.ca)

social network of... words?

This is weird, but brilliant

http://www.wordie.org/

Wordie lets you make lists of words ... and see who else has listed the same words.

via LibraryThing blog

auditor general - large IT projects problematic

The Auditor General of Canada, 2006 Report, Chapter 3 — Large Information Technology Projects.

# Overall, the government has made limited progress since our last audit of IT projects in 1997. Although since 1998 the Treasury Board Secretariat has established a framework of best practices for managing IT projects, many of the problems we cited in past reports have persisted.
# The quality of governance varied widely from project to project. In four of the seven projects we found that governance responsibilities were not carried out adequately because key issues that impacted project performance were either not reported or not resolved.
# Five of the seven projects we looked at were allowed to proceed with a business case that was incomplete or out-of-date or contained information that could not be supported.
# Four of the projects were undertaken by departments that lacked the appropriate skills and experience to manage the projects or the capacity to use the system to improve the way they deliver their programs.
# Depending on the project, the quality of project management ranged from good to seriously flawed. In two cases, poor project management led to long delays and large cost overruns.

ancient device possibly decoded

Ok, I'll admit, this is just an excuse for me to use "Antikythera Mechanism" in a posting.

Nature 444, 534-538 (30 November 2006) | doi:10.1038/444534a; Published online 29 November 2006

In search of lost time

No earlier geared mechanism of any sort has ever been found. Nothing close to its technological sophistication appears again for well over a millennium, when astronomical clocks appear in medieval Europe. It stands as a strange exception, stripped of context, of ancestry, of descendants.

The Beeb summarizes it as Ancient Moon 'computer' revisited.

CARL and SPARC respond positively to CIHR draft research access policy

CARL = Canadian Association of Research Libraries
SPARC = Scholarly Publishing and Academic Resources Coalition
CIHR = Canadian Institutes of Health Research, one of Canada's granting councils

The press releases are both PDFs, for some reason.

The SPARC letter to CIHR is online at
http://www.arl.org/sparc/advocacy/canada/cihr_draft_policy_response.pdf.
The CARL letter is online at
http://www.carl-abrc.ca/projects/open_access/pdf/cihr_draft_policy_response.pdf.

The CIHR Draft Policy http://www.cihr-irsc.gc.ca/e/32395.html will govern peer-reviewed journal publications, research materials, and final research data stemming from CIHR funding.

In its response to the Draft Policy SPARC presents three recommendations for refinement:
- That grantees be required to comply with the policy;
- That the specifications for qualified archives and repositories should be explicitly detailed; and
- That articles must be deposited immediately upon publication in an open archive, but to offer the flexibility of allowing the grant or award recipient to perform the deposit or to require the journal (or another agent) to make the deposit on the researcher's behalf and in compliance with CIHR requirements.

The SPARC letter also highlights the importance of access to data: "As science becomes increasingly data-driven, the need to ensure broad, timely, and persistent access to this material rises in importance. We feel it is particularly notable that CIHR calls for grant holders to provide high-quality metadata to ensure effective future sharing of data and datasets."

In its response CARL asks that CIHR work with stakeholders
- To develop a Canadian-based solution for housing and making accessible the outputs of CIHR-funded research over the long term;
- To implement a more structured approach to providing access to research data; and
- To ensure that compliance to the policy is linked to future funding decisions.

via CISTI's Bev Brown

little SOA and the reusability debate

There's quite a wide debate going on about SOA.
Some issues include

• do you need it at all?
• how big (how complex) does it need to be?
• will it actually give the promised reusability?

I found some interesting postings, good discussion starters:

SOA What? Big vs. Little vs. Nothing at All - Josh Greenbaum - Enterprise Anti-Matter blog

the relative paucity of companies that today are betting their business on a SOA strategy — in an enterprise-wide way — has brought the market to an important inflection point. The need for comprehensive ROI data — as well as some good info on total cost of ownership — has never been greater. And until those data — that elusive business case — are readily available, the uptake of what I call "Big SOA" is going to be slower than most of its proponents would like. "Little SOA" seems to be where the action is for now — pilot projects, smaller, discrete implementations, and custom-built composite applications that deliver some immediate value to a specific line of business in need.

The ROI of Little SOA is easy to establish — these discrete little projects have a lot of potential payback, as they are addressing real pain with a real solution. The problem with Big SOA is that the pain it addresses is one we've gotten much too used to over the years. Costs associated with bad integration, lack of re-use, overall inefficiencies and the inability to truly address business needs with technology solutions have been with us so long that we hardly know they are there.

...

The alternative to Little SOA is none at all, and I think that's a major disadvantage for all concerned. Service architectures and web services are as inevitable as Moore's Law. What's needed is just a little more time to let the big ROI of Big SOA get established. In the meantime, there's Little SOA to keep us all happy, and that's not a bad thing at all. 

I think that's a pretty reasonable position, for large organizations.  Doing a true, "Big" SOA in an organization with substantial infrastructure and processes will be enormously disruptive if you do it properly.  I do however feel, that if your IT is relatively simple (say, a single catalogue system and some web pages), you can get most of the Big SOA advantages.  As long as libraries are collectively working on a bigger SOA then at most libraries, the actual activities will look a lot like Little SOA.

I do get worried when we talk up the merits of "discrete little projects".  Isn't that how we got ourselves into the silo mess in the first place?  One little app here, one little app there... Yes, I know, Enterprise Architects generally say "you always need an architecture".  But I'm worried about a slippery slope that leads to hundreds of un-coordinated Web Services.  That's no path to reuse.

In SOA in enterprises or Hype 2.0, Vilas asserts that we won't get real reuse from SOA, but that we should do it anyway.

[Hype] 1. Myth of reusable services

In my experience as architect I have never seen as-is reuse of a business service implementation. Some amount of refactoring is needed for it to be reused. The refactored business service actually harbours multiple services under a common facade.

...

[benefit] 1. Manageability of software with business alignment

The single most important contribution of SOA is that it connects software with business. In an SOA approach, one can make sure that all software is aligned with business needs, because all software is traceable to their business needs.

...

[benefit] 2. Ability to seperate concepts from implementation

The next important contribution of SOA approach is the focus it brings on seperating interface from implementation.

I think that's an interesting perspective.  We do need to be realistic about the "Holy Grail" of reusability, and not oversell it, as well as not overselling Big SOA.  But I nevertheless feel that some of us have to be trying big scale SOA, because quite frankly, how else do we move the software engineering framework forward?  The only alternative right now seems to be to have no architecture, to do some sort of rapid mashup stuff, which I think can't possibly be sustainable.  (I'm not saying rapid mashups don't have their place, and they are way better than spending a year waterfalling something that won't deliver, but you have to remember, An Application Is Forever.  Humans are terrible at stopping things once they start.  That's why you need a framework to make sure you're starting the right things.)

crossing categories

There's a good presentation about library SOA http://info.drc.ohiolink.edu/presentations/200611-uwindsor-soa/ that points to my Web Services category, you may also want to check my SOA - Service-Oriented Architecture category.

embarassed on video? ban the technology

A Gatineau, Que., teacher is on stress leave and his school has banned personal electronic devices in the classroom after a video of him shouting at a student was posted on the YouTube website.

École Secondaire Mont-Bleu has also suspended two [students].

CBC Ottawa - Quebec school bans cellphones after YouTube video - November 24, 2006

governments and social media

Ian Ketcheson, situated somewhere in this green zone we call the National Capital Region, has a blog category on Government and Social Media.

Shall we start a pool on when Government of Canada Internet policies will adapt to allow blogging by federal employees in any kind of reasonable way (by reasonable, I include "not having to completely redesign your blog" and "not requiring a team of translators and advisors")?

I'm putting my money on 10 years.

the Internet as a community-creation engine

From the earliest days of USENET, with its main.subgroup.subsection.subsubsection format, the Internet has enabled people to form communities of interest that are highly specialised.  Like most anything enabled by technology, this has its good and bad aspects.

Yes, jihadists can get together and tell one another what a wonderful thing it is that they are doing,
but so can anti-jihadists.

My favourite example of this narrowcasting, or nanocasting, is Flickr groups.  There are of course huge Flickr groups devoted to topics of typical photographic interest, like Sunrises and Sunsets (12,453 members).  But there is also the "I didn't think anyone else was interested in that" sort of groups.  For example, I like to take photos that are empty of people.  I consider humans to be noise that messes up the framing of my shots.  As luck would have it, I can submit my photos to the Flickr group

The Last Person on Earth (1,036 members)

(or see just my contributions)

This isn't even the only "no people in the photo" group, there's also

No people

Beyond that, in Lonely City, you can't even have animals in the photos.

Another fave of mine, mostly because I always like to see the fallibility of our technology pointed out, is Public Computer Errors.

Anyone else have favourite Flickr groups?

Last Person on Earth found via Darren Barefoot - Photos of an Empty Earth.

the Mac Dashboard Translator widget

You may not know (it certainly took me a long time to discover) that the Mac has a pretty good translation capability built-in.  There is a translator widget available in the dashboard.

For languages with Latin characters, it can be fun to try to puzzle out some meaning, but for Russian, Chinese, Japanese etc. I find this invaluable.  Just paste the text to be translated in the top panel (setting the languages appropriately) and the translation will appear momentarily in the bottom panel.  It accesses Systran to do the translation (hmm, like a sort of "web service").  Unfortunately, the window can't be resized (AFAIK) - it's only really suitable to do a short email or a paragraph of text.

my review of SOA for Dummies

Summary

I am reviewing this book primarily in the context of Service-Oriented Architecture (SOA) for Libraries, which is a rather dramatically different audience than it is intended for. 

I recommend the first three chapters of this book, along with the "loosely coupled" section of chapter 5 as a good introduction to this topic.  As well, Chapter 11, on SOA Governance, is excellent.  However, its main audience is large organizations (who are the main current adopters of SOA), so much of the content may not apply to libraries, particular those with limited technical resources.

Although the Dummies books proclaim "A Reference for the Rest of Us", this book would really more accurately be titled "SOA for Dummies... Who Work at Giant Fortune 500 Companies".  Much of the technology and processes they present are beyond the reach of all but the largest organizations.

To my surprise and dismay, there isn't a single mention of Enterprise Architecture (EA) in this book, whereas I feel that for the scale of organization this book targets, EA is absolutely essential.  Without EA, the scale of activities and technology described in this book is impossible.

There is also a very important discussion that needs to be had about agility versus structure.  I am not convinced you can maintain organizational agility as a goal, with the complexity of the management and technology structures this book describes.  The book does not address this issue at all.

Overall the flow of the book is a bit uneven, both in terms of writing style and in content, and it doesn't present a coherent "SOA story".  To some extent this is due to the nature of the Dummies books, where they want each chapter to stand alone.  I found it made for a bit of a "here's an important concept" ... "and here's another one, with some vague undefined relationship to the previous one".

This book will mostly give you a lot of "why" and "what" about SOA, not a lot of "how".  That is the nature of the beast, however - I don't think there's any other way to present it, with out it being a 3000 page book.

The companion website www.dummies.com/go/soafordummies is highly promoted on the front and back covers of the book but it does not seem to exist, which seems like a bit of rather bad planning.

Sidebar

UPDATE 2007-08-09:

If you're coming here from SOA Center, you may be expecting Beth Gold-Bernstein's review.
The SOA Center link is currently wrong.  She blogs at ebizq:

July 24, 2007  Beth Gold-Bernstein  SOA for Dummies
July 31, 2007  Beth Gold-Bernstein  Reactions to SOA for Dummies Book Review (in which she refers to my review as having some similar points to hers)

I did leave a comment on SOA Center correcting the link, but it has not been posted.

ENDUPDATE

Details

I don't come to this book with a blank slate, quite the opposite, I've been trying to find ways of clearly explaining SOA to both business people and technical people for the past few years.

Just to stake my prior claim, I think I did a pretty good job in my December 9, 2005 presentation "Service-Oriented Architecture Methods to develop Networked Library Services" (video, PowerPoint) which predates this book by about a year.

It is a difficult story to tell to be sure.  To my mind, SOA sits at an intersection of Enterprise Architecture, software engineering, Web Services, business and technology.  So in a way, the challenge is "let's take a bunch of things that people don't understand, and try to explain a layer on top of them, that depends on all of them".

Also, in the interests of transparency, the informal style used in this book is not one that I enjoy for learning.  My ideal informational book is just facts piled upon facts - I don't need a story, or to be put at ease. 

I tried in my analysis to ignore that stylistic aspect, as well as trying to come with as blank a slate as possible, keeping in mind I've been deep into SOA for the past couple years.

Here are my thoughts, chapter by chapter.

Chapter 1 - SOA What? (this makes more sense if you pronounce it so-a, as the authors do, rather than S-O-A)

All of Chapter 1 (PDF) is available free online from Wiley.

They talk about their audience, but I do think they make a mistake in not scoping the book.  The full SOA they describe in the book's 300+ pages is one that could only be used by a large organization.  Think, General Motors revising their information technology, not Bob's Corner Store.  They should have made it clear that you can adopt some SOA concepts, without going to the full, complex, vendor-rich (and vendor-enriching) extent that they document.

For example, they start out with some clear explanations about how SOA is an enabler for business to work better with the IT department.  You may at that point be thinking, "my problem is not working with the IT department, my problem is I don't have an IT department".

So in reading the book, be mindful of their audience.  And also, I suggest you think of how SOA could help the entire community of libraries, collectively, if the scale of your individual organization is not appropriate for SOA.

They do extract good key points, like the fact that reuse is at the core of the SOA goals and methodology.  At this level, they face a challenge that I don't think there is a good solution for, which is that you have to talk a lot at the beginning about SOA "why" and "what", without being able to easily walk through a lot of SOA "how".

I also think that their definition of SOA is a bit over-broad.  Some of what they describe as SOA is what I would consider Enterprise Architecture (EA).  Now, I certainly think SOA works best within an EA context, but there doesn't seem to be any mention of EA at all.  So I disagree when they say

1. The IT organization will partner with the line of business managers to create a high-level map of what the business will look like.

That surely needs to be done, but that's EA, not SOA.  To me, Service-Oriented Architecture is just the architecture of the services, not all the processes of business process analysis as well.

Chapter 2 - Noah's Architecture (oh I get it -- literally, just now - it's a play on words, see.  sigh.  I spent the entire chapter wondering, what does Noah have to do with it?)

So at this point, the conceptual assault really gets underway.  To get to the heights of SOA, you have to build concept upon concept.  Unfortunately, each one of those concepts could be a book in itself, and here they get a couple pages at best.  I'm not being critical - I don't see any other way you could do this, and it's the same approach I have used, but I can imagine it being overwhelming reading for someone coming from outside a software engineering background.

They give an ok explanation of software architecture, and hit the high points of the history of software engineering that got us here.  I liked their mentions of business logic and the key concept of separation of concerns.  Again, they are talking about big organizations, for example, on page 16, they state

In the Good Old Days, a business unit would ask the IT department to create an application to solve a specific problem.  To accomplish this goal, the IT department would write a set of customized programs.

This is absolutely, 100% true.  For a certain scale of organization.  If you're thinking instead, as I mentioned before, "I wish I had business units.  Or an IT department." then SOA may not be a good match for you.

They then take a bit of a side trip into components.  I'm not sure I would have used this terminology.  It's certainly true that we tend to run out of useful worlds to describe certain concepts, but to me components are about a specific subfield of software engineering, Component Based Design.  Software components have a very specific meaning, a meaning which is different from the one given in this book.

This is important, because if you read this book and say "component" to an IT person, they may not have the same understanding that you got from the book.  In a similar channel, the use of "plumbing layer", which is continued throughout the book, is most unfortunate.  "Infrastructure" would have been a much better choice.  Whatever dubious merit there is in the informal term of "plumbing" is going to be lost the first time a non-tech person uses the word to a technical person, and the technical person thinks "Plumbing? What the heck?  Is this guy an idiot?"

At this level, there does have to be a bit of "hand-waving" over the explanations, this is particularly egregious (although the authors themselves acknowledge this somewhat) in the "simple adapter" explanation.  Adapters are probably some of the most complex challenges an organization faces in transitioning to SOA.

I did enjoy the brief excursion into "application archaeology", particularly since my original SOA presentation on SOA had a slide or two on this concept, with a nice quote from Vernor Vinge's writings, but I had to take the whole segment out because people said "application archaeology, what the heck were you talking about there?" (I'll try to dig up the quote, it's excellent.)

I'm also not a super big fan of the "black box" terminology used, but it does capture the concept well enough I suppose.

Chapter 3 - Not So Simple SOA

A bit of a jump from components to Web Services, with a bit more handwaving.  I also didn't like the strong link between Web Services and SOA.  While their statement that SOA is not Web Services enhanced (or I guess I should say "is not Web Services 2.0") is certainly true, it's also true that you can do SOA without Web Services at all.  The two are, as we say, loosely coupled.

There's also a bit of a jumble about business processes, I'm not sure it fits well within this chapter.

Finally, while silos are mentioned, I think they really missed an opportunity to emphasize a key failure of siloed software - that it locks up useful services deep inside the silo, where no one can get at them.  This aspect is mentioned only in passing.

All those caveats aside, I did feel that Chapters 1-3 are about as good a clear explanation of this extremely layered concept that you can get (well, that is to say, almost as good as my explanation :)

You should really jump from Chapter 3 right to Chapter 5, I'm not sure why they placed Chapter 4 here.

Chapter 4 - SOA Sophistication

Woo boy.  Chapter 4.  If you are coming from a small organization, or a non-technology background, your service experience of chapter 4 will be akin to hitting a brick wall.  Chapter 4 layers on the SOA "essentials" at a breakneck pace, presenting as essential elements of SOA things that are, each of them alone, HUGE complex business activities.  We are definitely into the General Motors scale here.  The Galactic Motors scale, in fact.

Let me make it immediately clear: I do not personally believe you need all of the stuff they describe in order to use SOA, and to participate usefully in an SOA.  The basic SOA methodology can be used by almost any organization that has at least some idea of its basic business functions (and some business decisionmakers) and a small IT group to design and build services.

So, what are the bricks in the giant Chapter 4 wall?

• Enterprise Service Bus (ESB)
• SOA Registry
• Workflow Engine
• Service Broker
• SOA Supervisor (about which, I have more to say)
• Business Process Management (BPM)
• Service Level Agreements (SLAs)
• Automated Service Monitoring (related to SOA Supervisor)

In looking at that list, my first reaction is "hmm, are there any 30 million dollar cheques I haven't cashed yet?" and secondly, that almost anyone, even someone from a large organization, who reads this chapter is at great danger of rejecting SOA out of hand.  You're telling me that SOA is going to improve my organization by adding re-use and handling complexity, and you want me to add a gigantic laundry list of complex technologies (many of which don't yet fully exist) to my organization?  No thanks.  Call me in 10 years when you've got it all figured out.

Now I want to be clear: all of these are important aspects to consider, and many of them will need to be adopted, by very large organizations with huge numbers of services.  But I imagine that most libraries will have a handful of services - the basic functions that the ILS performed, plus a few others.  That doesn't require anywhere near the scale described in Chapter 4. 

I have certainly advocated that the most important piece I think will need to be layered on the base SOA is workflow, the orchestration server (you can listen to my presentation - yes, I will put the slides online eventually too).

I also want to address the SOA Supervisor, and the whole idea of automatically monitoring Service-Level Agreements.  I think this is very deep voodoo.  I am quite happy to be corrected, but I think this capability does not exist in any meaningful, easy-to-use, standardized way today.  To me, for SOA Supervisor, you might as well read SOA Magician, or SOA Magic Box.  It simply is not possible to perform most of the supervisory functions they describe, and even attempting to do so would be hugely complex and vastly expensive.

Chapter 5 - Loose Coupling and Federation

The loose coupling part of this chapter is good, but it really should have been separated out and put after chapter 3.  The Federation part only applies, as is often the case in this book, to very large organizations, that are so complex and diverse that they need to have multiple, federated, SOA domains, with a different set of rules applying in each one - think IBM HR SOA domain and IBM Supercomputing SOA domain.

(Note to CISTI architects: not the same as our domain concept.)

There is a bit of an overlong excursion into software-as-a-service (SAAS).  I think it could have been covered quite well by just saying "you may want to use external services, as well as your own internal ones".

I disagree quite strongly with the concluding section, which asserts that SOA is part of the industrialization of software development.  I certainly agree, and I have in fact asserted that SOA is simply our latest understanding of how best to do software development, but industrialization is way, way too strong a term.  Software is not constrained by the physical world, that's why you can't build software the way you build a bridge or a car.  I'm certain that Toyota knows, second-by-second and gram-by-gram, what is happening as a vehicle moves along its assembly line.  That is simply impossible for software, and it will probably never be possible.

Chapter 6 -  XML

To be quite honest, I don't really understand the emphasis placed on XML within SOA.  Thomas Erl certainly uses it as the keystone of the explanations he gives in his talks and books.  To me, you could get by with two sentences: "Software design works best when you can use standards.  XML provides the ability to create data standards."

This chapter goes into way way more than I think you need to know (for SOA purposes) about XML, SOAP, WSDL, UDDI and even (oddly thrown in) HTTP.  It also seems to express a view of XML as a sort of "magic glue" that ties different programming languages and systems together.  Um, we were able to connect systems together in the bad old pre-XML days.  We called it "using APIs".

Chapter 7 - Dealing with Adapters

This chapter starts out with a strong statement, unfortunately, one I disagree with

Adapters make SOA possible.  No adapters, no SOA -- it's as simple as that.

Um.  No.  I recognize that not all is green fields, but not all is layers and layers of legacy either.  This is coming from big corporation, banking thinking.  It is certainly true that when I enter a number on my bank's customer self-service website, it is going through layer upon layer of adapters, ending up at a mainframe Which Must Never Be Touched.

But for example, library catalogues?  You'd have to be mad to build adapters to catalogues.  Blow them up, replace them with a green field of services.

This chapter also creates a dependency between adapters and service registry and service brokers.  This is unnecessary.  It also continues the early "simple adapter" nonsense, on page 93

Technically, building an adapter isn't too difficult.

Um.  Yes it is.  What they're talking about is API Adapters.  My mainframe interface takes some ancient binary IBM format, and I wrap it with an XML adapter interface.  That isn't too difficult, yes.

But most of the problems facing libraries, at least, is that there is no interface.  There's nothing to easily adapt.  You have to write an entire interface layer.  That is hugely complex.  I have to imagine this also applies widely outside the library technology context.

I have to admit my final written note on this chapter reads, simply: this chapter is baloney.

Chapter 8 - The Registry and the Broker

We're now getting into more and more complex technology, and I'm getting more and more dubious about its actual existence and workability.  To be quite frank, unless I see lots and lots of demonstrations in the real world of this stuff working, I think it is a lot of wishful technothinking.  And I'm not convinced even if it was in place, it wouldn't create a huge agility barrier.

I'm in agreement with the people who say a UDDI service registry simply isn't going to be maintainable in the long term.  You might as well call it "the perpetually out-of-date service registry".

Chapter 9 - Enterprise Service Bus (ESB)

I'll willingly admit to some ignorance here.  We have certainly been discussion ESB at my organization, but we have yet to be convinced that it is necessary.

Again, there is a scale issue.  ESB is basically the reliable message queue idea.  You need a reliable message queue if every (service) message in your organization potentially has huge financial impact - that's the only thing that can justify the cost and complexity of an ESB.  For a big org, or one doing heavy financial stuff, this certainly applies.

To a library, loaning books for free?  If the occasional message drops, I think we can survive.

Chapter 10 - SOA Supervisor

This is currently indistinguishable from magic, which puts the lie to Arthur C. Clarke's famous maxim, because this is certainly far from being an advanced technology.

I'm not even convinced this is an existing technology.

Chapter 11 - SOA Governance

Excellent coverage of the transformational issues raised by moving to an SOA.  A must read for anyone doing a serious SOA initiative.

Chapter 12 - SOA Security

I'm not entirely convinced security is part of SOA, it's a separate service or services to be defined within the architecture.  But the kind of security they're talking about in this chapter is more "organization-wide complexity protection".  Again, the heavy-weight approaches they indicate are appropriate only to large-scale organizations. 

To get a taste, the essential pieces they recommend are:

• identity management
• software and data authentication
• audit trails

If you're not the scale or type of organization that has the above three concerns, you probably don't need to think too much about the type of security they are describing.

Chapter 13 - Where's the Data?

I have to admit a bias - I don't care about data.  I know however, that many EA people, such as Jane Carbone, consider data the essential starting point of analysis.  It is of course important that someone in the organization cares about the data, and this chapter has some useful guidance about the topic.

Chapter 14 - SOA Software Development

In this chapter, we get a little bit of "how".  But it's not really entirely about software development.

For example, I was again surprised to see yet another way to describe Enterprise Architecture, without saying "Enterprise Architecture".  This time they call it "building a business process map".

It then dives into iterative prototype development, which is all well and good, but not essential for SOA.  You certainly could develop services using the waterfall model.  Iterative prototype is certainly a good software development practice, but it doesn't have any strong connection to SOA in particular.

The last part of the chapter discusses Web Services and SOA testing, and this is an important topic which they cover well.

Chapter 15 - The Repository and the Registry

My concerns are as expressed about all these additional layers before:

• this is an important consideration for large organizations
• I'm not convinced anyone has technology that actually does this well in the real world
• I'm not convinced you can use it and still be agile

Chapter 16 - Do You Need a SOA?

Some relevant items for any organization, but some of their questions, e.g. #1 "Is Your Business Ecosystem Broad and Complex" apply again only to large organizations.  I think you can usefully have an SOA even if your business is simple and narrow.

Chapter 17 - Making Sure SOA Happens

Useful information, if a bit generically applicable to any type of major organizational change.

Chapter 18 - SOA Entry Points

Some reasonable guidance.

Chapters 19-26 are supposedly under the rubric "Real Life with SOA".  But I think more accurate would be "here are a series of chapters about major SOA vendors".  I was hoping for real organizational examples, but this section (which runs from page 225 to page 308) is mostly just "here is the SOA stuff from IBM / HP / BEA / Progress / Oracle / Microsoft / SAP / JBoss".  To me, it was a waste of almost 100 pages.  A single page pointing to the vendor SOA websites, with perhaps some of their key articles or white papers indicated, would have sufficed.

I think you've already seen from this review that SOA is a complex enough topic that 80 pages could have been usefully deployed for more explanation and for more discussion of the "how" of SOA.

We wrap up with Chapter 27 to 29, where we get some "Part of Tens" guidance and links, including even more vendor links.  My written notes conclude this part is "vaguely useful".

Overall, the book started very strong, and really could have been for the Rest of Us if they had continued in that vein, but instead it ends up being SOA for Really Big Business.

If that sounds like a good match for you, or if my review has piqued your interest, you can buy the book from my

SOA Book Store (powered by Amazon.com)
or
SOA Book Store (powered by Amazon.ca)

Wikipedia - Book Sources - ISBN 0470054352

the Wikinomic Generation

Don Tapscott is a bit of a "paradigm evangelist", which puts him in the business of perpetually declaring that everything is undergoing revolutionary change.

He does have some interesting ideas sometimes.  But to some extent I get a bit weary of this "old people try to figure out young people" stuff.  The young people can type too you know.  Why not have them report on themselves?

There's an article in the Post today, Net Generation 'wired' differently.

They value freedom This includes freedom of choice and of scheduling. For instance, some 42% do not watch television live but pre-tape to watch shows when it suits them.

"Primetime is now MyTime or AnyTime," he said. They also value the freedom to customize, mixing video, music and other content for their own use or to send to others.

They are scrutinizers "They have developed online and media BS detectors about everything. If they are on a social site they must determine whether the person contacting them is really a girl, a boy or a predator or their parent checking up on them?"

This is also why they rely on Jon Stewart or Web sites for news and information rather than the mainstream media.

I'm not sure this is necessarily Net Generation stuff.  Hardly anyone I know watches TV with the Real Timers any more, and we're all way past 30.  (Plus which "pre-tape"?  What's a tape?)  Many people are not just time-shifting, they are season-shifting, as they discover that two-or-three episodes on DVD a night with no commercials is a much more efficient and satisfying way to manage television.

I think it's important to understand that a huge amount of the "Internet transformation" stuff translates simply into: people are watching less TV, and in particular, they're doing everything possible to escape commercials, and to watch it according to their schedule.  This has marketers going mad, because there are literally billions of dollars of business done every year based on (in particular) selling free-spending American teen eyeballs to advertisers, and the eyeballs aren't watching TV in the same way.  MySpace, Second Life, and so forth: it's all a mad rush to find places where that vital service of telling teens what to consume can be performed.

I'm not sure "changes in general media consumption trends" translates into "revolutionary re-organizing of generational thought paradigms" but anyway...

Tapscott has a new book Wikinomics: How Mass Collaboration Changes Everything.

I suppose "some things may be changing although most of the technology is only 5 years old at most, so no one really knows exactly what it all means" would not have been as compelling a title.

Gratuitous Amazon linkery

Wikipedia - Book Sources - ISBN 1591841380

Previously:
June 06, 2005  blogging of Tapscott's keynote at SLA 2005

great science books - join the discussion

I noticed Discover's 25 Greatest Science Books of All-Time on the newsstand, and checked it out online.
I only got as far as the first page.  Voyage of the Beagle is a great book, and I highly recommend it (you can read my review).  The rest, are they nuts?  No general reader is going to slog through Philosophiae Naturalis Principia Mathematica, and even if they did, I don't think they would take much away.  In fact, most scientists would have a struggle to get through these.  The Discover list appears to be "most scientifically important / influential books", not "here are some good science books that you might actually want to read".

Confessions of a Science Librarian has pointers in Best and worst science books that lead to further discussions.

I do disagree with a couple books on the "worst" list (well, the only two books on that list I have read):

Drexler, Eric, Engines of Creation

Edelman, Gerald, Bright Air, Brilliant Fire

These books are both flawed to be sure, but I found them very interesting.  Well, ok, the second book consistently puts me to sleep, but the parts I manage to read before going unconscious are good.

research funding in Canada

Lots of good stuff over at Confessions of a Science Librarian.
Of particular interest to me is the recent posting Science funding in Canada.

Points to an informative article in the Toronto Star - T.O.'s research crossroads - November 9, 2006 ("T.O." is Canadian slang for Toronto, but the article addresses issues of general concern all across Canada)

Toronto risks falling behind in the global race to be a centre of excellence for research and development, according to a report to be released today.

...

The report suggests that Ottawa is doing much less to support research and development than other national governments, including the United States.

The 33-page report, entitled At a Crossroads [PDF], looks at nine leading centres of research in the United States (Boston, San Diego, Austin, Albany, and Raleigh) and overseas (Singapore, Bangalore, Shanghai and Stockholm) and suggests the common thread for all of them is major support from their national governments.

Meanwhile, says the report, under the Conservative government in Ottawa, key research agencies "have either reached the end of their terms or have received no word as to their future funding."In this respect, the report names the Canada Foundation for Innovation (which funds research infrastructure), Genome Canada (which supports genetic research), CANARIE (a national high-bandwidth network for research), and the Canada Research Chairs program (under which research talent is recruited to Canada).

...

What is causing concern in the R&D community — not only in Toronto but across the country — is the delay in publication of a science and technology "strategy paper" by the federal government. The paper, promised in last spring's federal budget, had been expected by the end of September. No such paper has emerged from the federal bureaucracy, however, and now there are indications that the R&D strategy will be condensed to a few paragraphs in federal Finance Minister Jim Flaherty's economic statement later this month.

Questions on the missing strategy paper to the office of Industry Minister Maxime Bernier, who is responsible for science and technology, were met with a boilerplate response.

Also in limbo are two major research centres in the Toronto region that were supported by the previous federal government under the Liberals: the National Institute for Convergent Technologies in Markham and the National Centre for Biomedical Innovation in downtown Toronto.

(possibly career-limiting) emphasis mine

The article also has a chart (PDF) comparing our research spending and tech salaries against other countries.

 

Pew report: the Internet as a resource for science

The Internet as a Resource for News and Information about Science

The report itself is a 42-page PDF.

via ArsTechnica

The Exploratorium  is a San Francisco museum dedicated to a hands-on exploration of science, and it views its mission as including public outreach and education. The museum joined forces with the Pew Internet and American Life Project, which is dedicated to analyzing the impact of the Internet on the US population, to examine how the public's use of the Internet is shaping their interactions with and understanding of science. The two organizations conducted a phone survey of 2,000 adults at the start of this year, and the details of the survey and an analysis of the responses were both made available [Monday November 20, 2006].

Consistent with the view of the Internet as an information gathering tool, most users started their trips into the scientific web through a general search site, and couldn't remember any specific sites they had visited. The use of multiple sources is reassuring, in that it suggests that most users do not accept a single presentation on a topic as the final word; a full 65 percent also noted that they did not view "too much information" as a problem. Intriguingly, many checked their internet sources against more traditional print information, such as encyclopedias and scientific journals.

50 Years of The New Scientist

Instant Expert: 50 Years of New Scientist - the Best Articles

Second Life on First Life TV

I think that the Reuters presence in SL got the attention of a lot of other newsagencies.  CISTI's Michael Ireland pointed out that there was a report on CBC TV's The National last night (this is the flagship news programme from our national broadcaster).  They had a ten minute report--that's a major amount of time for a TV news show to devote.  It's not available as a separate segment online--I have emailed them and asked them to "liberate" it.

UPDATE 2006-11-22: Colin located the story, including links to the video segments.

CBC - Reports from Abroad - Adrienne Arsenault - London File - On the vagaries of a Second Life - November 21, 2006

I bow before the linkmaster.

ENDUPDATE

John had a look around and found some other TV news reports about Second Life.

RIN study on researchers and discovery services

Some great and very necessary foundational work studying researchers and discovery services, from RIN in the UK.

interviews with some 400 researchers and 50 librarians from a range of institutions and subjects and geographical locations

The report is 113 pages long :(

I've printed the first 10 pages - looks like interesting stuff.

via RSS feed RIN - What's New

As this study shows, researchers devote considerable amounts of time and effort to using a wide range of services to find the even wider range of information resources they need to pursue their research.

virtual poverty in Second Life

I quipped to Steve that being a newbie with a free basic Second Life is a bit like being virtually homeless - you have no money and no place to stay, you don't know anyone and all you can do is wander around aimlessly, looking at things you can't have.  A very disconcerting experience, really.

webomatica expresses this experience well in the posting Second Life: I Have 4 Dollars

InformationWeek on Web 2.0 infrastructure

In Under Construction, InformationWeek identifies six critical infrastructure areas needed to support robust Web 2.0 services:

• Scale
• Content Management
• Security
• Lightweight Development
• The User Experience
• Communities

They also provide a timeline highlighting some of the history of the web / web 2.0

Thomas Homer-Dixon on TVO

He's going to be on in about 15 minutes, at 11 PM, on TVO's Allan Gregg in Conversation.
There are two video links available.

Web Exclusive Preview: Allan Gregg in Conversation with Thomas Homer-Dixon

Web Exclusive: Bonus footage of Allan Gregg in Conversation with Thomas Homer-Dixon

The show repeats on:
November 20 [2006] at 02:30 AM
November 25 [2006] at 05:00 PM

Previously:
November 05, 2006   wise crowds ruled by foolish governments?

meta: 2 years of Science Library Pad

As you can see from the archives, Science Library Pad is two years old tomorrow, Monday November 20, 2006.

I started it mainly to have a more professional place to post conference reports, and then it evolved into a much greater communications channel than I ever could have imagined.

I'd like to thank everyone who subscribes, and particularly those who comment or email me.  It's great to make connections into the worldwide library / science / publishing community.

I think this is my 1380th post.

The rest of this post is stats mainly for my own interest, what's a blog without some narcissism?

Also note that various blog monitoring tools were added at different times, which is why they don't all stretch back to day zero.

Feed Stats

Steady growth, now pretty much stabilized around 575.  The big jump was TypePad-FeedBurner integration.  The subsequent drop from the plateau is some unfortunate TypePad-FeedBurner disintegration (FeedBurner blames it on Bloglines) - it's not a real subscriber drop, just as the jump was not a real subscriber jump - it's just capturing a greater or lesser subset of the real subscribers.

By far--very far--the most popular post in the feed is the controversial is the research library obsolete?

Total  	                           44,975
is the research library obsolete?   4,452
Alvin Toffler on Big Ideas 	      199
Seed Magazine on Open Access 	      180

Web Stats

Hits are pretty consistent, with rare peaks.

The big peak is when I got diggdotted. The small one I think is the controversy I stirred up with the "obsolete" article.

StatCounter has tallied 119,783 page loads and 87,687 unique visitors.

TypePad, which has the full hits picture (if very poor web stats tools) reports 128283 page views.
Also 277 comments and 84 trackbacks.

Last but not least, here's a Google Analytics map showing a sample of 500 hits

Previously:
August 24, 2006  meta: one hundred thousand
December 22, 2005  year-end wrapup
October 24, 2005  to every season turn turn - one year of scilib blogging

Canada library building in Second Life

I don't actually know who is involved with this project, but here it is, on Cybrary City

I don't think "Canada House" is a good sign though, as in the real world it means the building for the High Commission in the UK (Wikipedia - Canada House).

UPDATE 2006-11-21: I've spoken to the creator using a strange non-Internet device, the tele-phone.  She's open to ideas about how to use the space.