The Access 2007 website is up. This year the conference is being held in Victoria, BC. I always highly recommend this conference to library technology practitioners. As their tagline says, it's "Canada's Premier Library Technology Conference". Access 2006 was held this past October in Ottawa.
Dion Hinchcliffe has a very interesting post entitled Eleven Emerging Ideas for SOA Architects in 2007. I really like Dion's list, particularly the idea of SOA being enabled more directly to the user. He suggests that making services consumable in the browser (via REST or similar), making AJAX the face of your SOA, providing access to SOA services via widgets. In other words, he's recommending starting to externalize SOA in different ways more directly to the end user. This is an idea for which I'm very much in favour.
He also mentions the statistic that 48% of CIOs will be looking to actually start using their SOAs to connect to external partners this year.
This gives me hope. We've spent the last 2-3 years building architecture and communicating SOA, followed by our first real SOA/EA based projects. We're just now reaching a place where we'll have services available internally, and ready for the acid tests of reuse (let's see). In my opinion, it's taken about 3 years for us to be poised to be seriously considering extending/exposing portions of our SOA in various ways. The 48% stat makes me think we're in a good place on the curve, particularly for a small organization.
Enterprise architecture is the planning process of an organization that leads to the implementation of business strategy and processes.
I've intentionally left out the words technology and models. Models are tools for communication and doucmentation. Technology is a tool that is often used these days to achieve the ultimate goal of enterprise architecture. EA could be equally applied to a lemonade stand as it could to a multi-national corporation, the methodology remains the same. Architecture is not, ultimately, about technology... though it is very practical to use EA as a planning tool that, of course, often includes technology as a very important aspect.
Wikipedia provides quite a good definition that's perhaps more accurate and less broad than mine:
Enterprise architecture is the practice of applying a comprehensive and rigorous method
for describing a current and/or future structure and behavior for an
organization's processes, information systems, personnel and
organizational sub-units, so that they align with the organization's
core goals and strategic direction.
The technology aspect that tends to be applied to EA I find blinds many to it's true objective. Technology is really just a means to an end. Perhaps a less zealous way to state things might be that Enterprise Architecture is equally concerned with people and business processes as it is with technology.
And one more that he does not explicitly mention, but that I think is a very important one for organizations newly undertaking architecture and technology practices: become comfortable with the not knowing.
All too often I've seen all sorts of projects and initiatives fail due to the very human desire (some would say need) to know it all up-front. This is impossible. Deal with it.
Yes, the architect will work with you to provide a broad scheme... blueprints if you will for the planned vision. This is not a detailed plan, just an overview. There are still risks, and unknowns. As you work though the plan (via projects), you identify and manage the risk. You cannot -- must not -- stall progress until all the unknowns are known. You'll wait forever.
I'm especially interested in exploring what I've been calling the because effect.
This is what you get when your new business isn't just about inventing
and controlling technologies and standards, but about taking advantage
of the new opportunities opened up by fresh new technologies and
standards. For example, making money because of blogging, or RSS, or desktop Linux, or whatever — rather than just with those things.
The because effect is a kind of jujitsu. While other people look to make money with something, you're finding ways of making money because of something.
Prime example, because of search, Google and Yahoo make money with advertising. Another: because ofRivendell, Salem Communications saves money with its core buisness, which is broadcasting. Because ofhis blogging, Thomas Mahon makes more money with his tailoring business.
I'm not quite sure how this fits with my world... perhaps: because of SOA and web services libraries are able to extend their holdings and services well beyond their traditional means and are able to work together to enable better service for their patrons?
Or: because of SOA, libraries are no longer dependant on siloed vendor systems and are able to make their technology infrastructure service their true needs in a digital world.
I was sent a really neat link to a Periodic Table of Visualization Methods. It's of interest to me as an architect that's always trying to find innovative (and concise) ways to explain complicated concepts. Whilst we do have a very good and working modelling practice that's based mainly on data flow diagrams (DFD), sometimes it's nice to present concepts differently, particularly if you're trying to converge in a particular direction, or to solicit new inputs.
We're always challenged when we're producing "presentation level" models... in that the somewhat sterile architecture models probably don't always evoke the desired response. In these cases the standards often go out the window and we attempt to present in most effective (and interesting) way possible.
Andre Vellino, newly appointed to CISTI's Research section, has started a new blog -- Synthèse -- about his experience and work at CISTI and areas of particular interest to library technology and scientific research.
I intend to present some thoughts about information retrieval, logic
and cognitive science as well as electronic libraries and information
management. I hope it will cover a broad spectrum of subjects and live
up to its name.
The architecture group expects to be working closely with the research group and with Andre. It's not often that I've heard of a close link between architecture and research, but I can imagine some good and positive possibilities from such interactions, particularly with the small teams and organization here at CISTI. I wonder if others have engaged in an architecture process in collaboration with a research group.
Our current expectation is that research would be looking farther outward - say 5-10 years in timeframe, whilst architecture usually sets it's targets closer to the 2-5 year span. Both groups are forward looking, but in different timeframes and contexts.
Students who would like to apply for summer jobs at the National Research Council (of which CISTI is a member) may apply online.
The deadline to apply is January 31 2007.
The NRC Summer Employment Program provides students with practical career-related
experience in research and development, library sciences, communications and
The Summer Employment Program offers students a challenging and intellectually
stimulating environment, while providing them with access to superior equipment,
facilities and expertise. Summer positions are offered at NRC institutes and
corporate offices. Each term lasts for a period of approximately sixteen weeks
(four months). Salaries are based on the number of academic terms a student