Making it stick.
Saturday, March 13, 2004
  Leveling the Playing Fields: More for All

And most of all, Cook wants to fix health care. ?When you move the work to India and China you get an immediate $6,000 savings right there,? he says. ?It?s huge.?

Who pays for this savings? Healthcare in these countries is horrible, especially for the millions of poor people who don't work for the elite corporations. The infrastructure, aside from what the elite corporations are building for themselves, is equally horrible,

How can a country, such as the US, that has taken such advantages as to provide at least a reasonable amount of healthcare for most people, as well as sanitation, transportation, and many other services for all, compete with a workforce not based in an equivalent healthy society?

I think there are two imperatives:

These are two ways to "grow the pie" for all of us, to address imbalances that have been falling out of balance for decades with too little leadership. Discuss these ideas and others
Thursday, March 11, 2004
  Politics are *about* flip-flops

A list of Bush flip-flops to counter their list of Kerry flip-flops.  

  Is Oblivity a Word?

Well, at least we don't treat electronic voting any differently than we treat other critical computing activities.

David Hart, chairman of Texas-based Hart InterCivic, which manufactured Orange County's voting system, said it would be impossible to identify which voters cast ballots in the wrong precincts because of steps the company had taken to ensure voter secrecy. For this reason, an exact account of miscast ballots is impossible.  

Wednesday, March 10, 2004
  More on Smalltalk's Image

Ian points out...

The image isn't strictly required -- I believe GNU Smalltalk has no image, or at least got along without one at one time, and the Smalltalk-ish Objective C has no image.

And instead of a single-process image, Gemstone Smalltalk uses a multiple-process, optionally distributed obect-oriented database

  The Public Good

Chomsky... claims that in the last 30 years, the economy is working well because of public spending on such technologies as computers, satellites, the Internet and lasers that has fed the economy. And the wealth derived from these technologies has gone primarily into the hands of corporate masters, who represent a fraction of the American people.

I believe we need a public investment in photovoltaics comparable to the investment the US government made in integrated circuits in the 50's, 60's, and 70's. Goals for distributed, local-scale, electricity generation would be far more beneficial for the US and for democracy and freedom than a trip to the moon.  

Tuesday, March 09, 2004
  Smalltalk is *too* good for its own good

Begin Update:
Ian continues...

Smalltalk code feels organic and extensible, but it's not well congealed into something as distinct as a "program". The current computing world is a world of programs, not objects. Maybe we'll get to that world of objects, but there needs to be a path leading there that starts here.

So maybe my new conclusion is that Smalltalk is uncompromising in its vision, but the world is not ready for that vision.

Smalltalk is *too* good? I would agree that Smalltalk still (after thirty plus years) seems ahead of its time. But I've seen large programs in C++ and Java become far more unwieldy mostly because they lack the *tools* that make exploration possible.
End Update

There are too many places to begin refuting this critique of Smalltalk, but let's start here as a place holder...

You can't easily map C or other libraries into Smalltalk.

Wrong. It's been a while since I've had to map C to Smalltalk, but even eight years ago it was so easy I was calling SAP R/3 functions from Smalltalk with just a few lines of code, and just an hour or so effort (for the first time I called SAP R/3 from *anything* and SAP R/3 is about the strangest thing I've ever had to call from any language).

It doesn't help either that Smalltalk's OO nature encourages everything to be a framework, instead of building mere libraries, but that's a topic for a different day...

Let's hope Ian gets to this someday. I have no idea where he's going with this.

I think it's wrong to underestimate the problems with Smalltalk's system image...

Maybe listing *one* thing wrong with the image would be a start. One can criticize anything, but an image file is just a convenience that other programmers struggle to emulate more or less in other language systems.

Sorry, I don't see much in Ian's critique to sympathize with. Least of all the "it looks strange" argument. Sorry, get over that one already, or ignore Smalltalk altogether. It's that simple.  

Monday, March 08, 2004

Ramkumar Kothandaraman writes about some of the business-level complexities I mentioned a few weeks ago. I wrote...

Although the infrastructure is still immature, the real problems for the enterprise are at the boundary where the services architecture meets the business architecture. The real problems of heading toward a world of rich services is how to get them to play at the business level. How do you keep them agreeing on a correct chart of values, a correctpart and product hierarchy, roles and responsibilities, up-to-date with engineering change notices, etc.

As Rumkumar points out from his experience...

[It] is very easy draw service boundaries that may create data related problems later on...

things started falling apart the moment we started integrating different services. The main problem we faced was that the 'Customer' entity is required by all the systems...

So, we went down the path of building a common module (system of record) for common entities. Things worked for a while, before we got into implementing a scenario that actually required a cross-join between product entity and a related entity owned by order management service...

So, what is the solution? Here is a practical one. "Try to share the database between related services....

For example, think of your favorite ERP system (SAP, Peoplesoft etc) as a business service that exposes one more services - one for HR management, one for Inventory, one for Order management, one for Accounting etc. But, they all share single logical data model. Ever wondered, why big ERP systems such as SAP have a single database that contains the tables required by all the modules? I tend to think this is the reason why they did it.

This problem is not insurmountable, but neither is it easily solved. Note this problem has nothing to do with your business and my business agreeing on a common Internet data model. This problem exists solely within the intranet of your business. This is just the tip of the iceberg toward a complete "service oriented architecture".

Note also I suspect vendor consolidation will accompany the move to SOA...

These are not insurmountable. To reiterate I believe the movement toward an SOA will be preceeded by a movement to realign IT for the enterprise architecture and go hand in hand with vendor and product consolidation, and less custom development.

In part this could support "service" vendors to actually gravitate around *databases* as a coordination mechanism rather than pure services, with some services privileged to create and update certain domains of data. Realizing this from experience through vendor agreement and implementation may take some time however.  

Patrick Logan's weblog.

March 02, 2003 / March 09, 2003 / March 16, 2003 / March 23, 2003 / March 30, 2003 / April 06, 2003 / April 13, 2003 / April 20, 2003 / April 27, 2003 / May 04, 2003 / May 11, 2003 / May 18, 2003 / June 01, 2003 / June 08, 2003 / June 15, 2003 / June 22, 2003 / June 29, 2003 / July 06, 2003 / July 13, 2003 / July 20, 2003 / July 27, 2003 / August 03, 2003 / August 10, 2003 / August 17, 2003 / August 24, 2003 / August 31, 2003 / September 07, 2003 / September 14, 2003 / September 21, 2003 / September 28, 2003 / October 05, 2003 / October 12, 2003 / October 19, 2003 / October 26, 2003 / November 09, 2003 / November 16, 2003 / November 23, 2003 / November 30, 2003 / December 14, 2003 / December 21, 2003 / December 28, 2003 / January 04, 2004 / January 11, 2004 / January 18, 2004 / January 25, 2004 / February 01, 2004 / February 08, 2004 / February 15, 2004 / February 22, 2004 / February 29, 2004 / March 07, 2004 / March 14, 2004 / March 21, 2004 / March 28, 2004 / April 11, 2004 / April 18, 2004 / April 25, 2004 / May 02, 2004 / May 09, 2004 /

Powered by Blogger