Adventures in home working

HP have posted a short article on the role of the Architect throughout the IT project lifecycle.  I like the perspecitive as often the dominant role of the Architect is the "design" role, and this is the one that is most repeatable and easy to capture in methodology.  The following picture provides a summary of the idea, with the yellow boxes representing the roles, and the ovals the phases.

The whole article is available here. but this is a summary:

The following sections map the the responsibilities and associated skills and capabilities of architects onto the Architecting Process. The responsibilities may fall to a single architect, or be distributed among a team of architects. Thus, someone on the team must play the role of leader who is empowered by management and the architecting team to make decisions that stick (the "architect with a baseball bat"). Others on the team may take on implementation responsibilities during prototyping or technology evaluation. If the architecting team has a project manager, that person may take on much of the "up and out" communication responsibility in addition to handling the personnel interface. Nonetheless, the lead architect must have a good proportion of the skills and capabilities identified below. The rest of the team must be good collaborators, modelers and system thinkers with significant experience in the domain.

- Posted by Steve Richards - 8:35:33 PM - comment []

Its interesting to see the slow but sure emergence of middleware to exploit XML documents.  Microsoft have WSS which can manipulate Infopath docuemnts stored in its document libraries for example.  InfoWorld report on a mor ambitious tool from IBM, code named Project Cinnamon, you can get the full details here, but here is the real content:

Cinnamon was born in IBM's Almaden Research Center and is a tool designed to automatically create mappings among different forms of data. By allowing users to define how an XML document gets mapped into a database such as DB2, the technology makes it easier to store those documents and to manage their content.

The upcoming utility hopes to address one of the thornier problems associated with XML-based development. Although XML serves as a clear standard for how content in a document is defined, the schema or definition of that content can be markedly different from document to document. This makes it impractical to place thousands of different documents in even a single data source and be able to retrieve certain data using a single search engine, an IBM representative said.

InfoWorld also says:

Some analysts think the upcoming technology can play a central role in helping corporate users crystallize the implementation of their Web services and SOA (service-oriented architecture) visions.

It may play a part, but I think "central role" is over stating it a bit.

- Posted by Steve Richards - 8:17:30 PM - comment []

Computer World has an article on this topic, most of which has already been debated many times with simillar answers to the ones that CW gives.  However I repeat the list here, because item 5 on the list is actually new to me:

1. Support availability
2. Functional limitations of the software
3. Software license terms
4. Rapid software release cycles
5. Package road maps or future plans

Items 1 to 4 are answered pretty well, and I don't think are a major concern now for most companies and the service offerings are developing at a rapid rate.  However here is the answer to item 5:

Package road maps or future plans are important to most companies. Major vendors tend to heavily promote their road maps, even to the extent of publicizing future capabilities years in advance. Of course, there is no promise that any advertised feature will ever see the light of your computer display. Not all vendors publish such road maps, and some share them only with strategic accounts under nondisclosure agreements.

Some open-source groups publish road maps, and some do not. At times, the stated goal is to mimic the functionality of a commercial package, though when any particular feature will appear is anyone's guess. The best advice is to make decisions based on what you can see and touch. If a feature doesn't exist, assume it never will, even if it shows up on a road map or vendor presentation.

With all these potential drawbacks and pitfalls, why would anyone consider using an open-source package versus buying a proprietary product? Ultimately, it's not about cost, so forget all those total cost of ownership arguments. It's about value and free-market choices. With any software acquisition, evaluate needs, explore options and select the best fit. Think of open-source as buying software from a small supplier. There may be additional risks, but the rewards can make it worthwhile.

 I am not sure I agree with the conclusion that you should "Think of open-source as buying software from a small supplier", in my eyes for many of the major Open Source development projects you are actually buying into a roadmap dictated by an asset thats owned by and will increasingly run the world.  Imagine all of the different agendas that will need to be accomodated when Open Source gets that popular, and the challenges that will exist to stop it branching in a way that damages compatibility.  Lots more on this topic to come I think, but thats the first thought that popped into my head at 1:00AM when I should really be in bed, but am not able to sleep because of the blasted Steroids I have to take, that give you insomnia!!

- Posted by Steve Richards - 1:07:47 AM - comment []

Ed Brill makes a point in one of his posts about the woes of the Exchange Group in Microsoft, here is the guts of it:

It hasn't been a good few months for the Exchange product team at Microsoft.  First the Outlook team ships an updated connector for Lotus Domino; then they dismantle their own roadmap; and now they are facing internal competition:

"Our first product here is going to be using Outlook that uses the Hotmail e-mail infrastructure. So you don't need to have an Exchange Server if you're a small business; you can just use Hotmail and you can have that synchronized experience, as well as the calendaring and everything else with other people who are on Hotmail."

Sort of confirms the feeling I got when I posted on a simillar topic a while back.  Then I got a bit more encouraged when I posted this.  lets hope for some clarity soon!

- Posted by Steve Richards - 12:51:57 AM - comment []

I wrote about this topic a while back.  Its nice to see some discussion starting up on it for two reasons:

1. Its really interesting, and a topic that deserves more public debate
2. I want to do some research on it, and need all the input I can get.  My own blog is sort of work in progress research but I want to spend a month or so giving it some real attention

Check out this post which gets the debate started.  Eric Mack has a real good contribution.

In fact if you are interested in personal productivity in general then the discussions on the Getting Things Done site are of a very high quality.

- Posted by Steve Richards - 12:42:13 AM - comment []